[DGD] happycode in DGD

[bart at wotf.org]

Seldom this gets done without creating one or more mockups to validate ideas.

Bart

On Sat, 7 Sep 2013 15:54:48 -0700, Raymond Jennings wrote
> 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
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/