[DGD] happycode in DGD

[Raymond Jennings]

Of course, but you still have to get a sane blueprint from an architect
before you can hire the actual masons and plumbers to build the darn thing.

Without the architect doing his job, the plumbers and masons won't be able
to even start theirs.

I have to make it look good on paper before I can make it work well in
practice.


On Sat, Sep 7, 2013 at 5:57 AM, <bart at wotf.org> wrote:

> On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote
> > thanks to an enlightening chitchat with aidil, I think I have a basic
> > gameplan for implmeenting happycode in DGD
> >
>
> Just for some background on this.. what I pointed out to Shentino is that
> 'anonymous' to LPC code does not have to mean 'anonymous' to the driver.
> Additionally, that one can make the assumption that anonymous functions
> only
> get updated code when taking a new reference (creating a new pointer to the
> anonymous function) while existing function pointers to it should be
> treated
> as 'data', ie, they may need conversion on upgrades (taking a new reference
> for example) but this can and should be handled by lpc code, not the
> driver.
>
> What this doesn't address is making such anonymous code run in the context
> of
> the function that defines them as would be needed for 'true' closures, BUT
>
> Actually, per statements from Wodan, the current maintainer of FluffOS (the
> maintained descendant of mudos), that isn't entirely needed to begin with
> since all local variables are actually passed to the closure and not
> actually
> shared, but object global variables are shared. So.. we just need to pass
> the
> values of local vars (easy, can be stuck into the arguments list of an fp
> with
> help of a little 'glue') and provide access to global variables, including
> being able to change them and have those changes reflect properly in the
> defining object (not so easy if this still has to work after the current
> 'task' finished, as all your data is now in another object (the happycode
> containment object) and should become a copy, similar to what happens with
> arrays, mappings etc)
>
> To me that means a closure would on one side need to be its own object so
> they
> can survive recompiling the defining object, but they'd also need to live
> in
> the dataspace of the defining object.
>
> Sounds to me like it'd need some kind of halfway in-between LWO and
> heavyweight object.
>
> You propose some magic with variables, I'm not sure that will work, but as
> said, proof of concept code tells me much more then any amount of design
> document :-)
>
> Bart.
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>