[DGD] happycode in DGD

[bart at wotf.org]

On Sun, 8 Sep 2013 17:30:38 -0500, Jared Maddox wrote
> > Date: Sat, 7 Sep 2013 14:57:03 +0200
> > From: bart at wotf.org
> > To: All about DGD and Hydra <dgd at dworkin.nl>
> > Subject: Re: [DGD] happycode in DGD
> > Message-ID: <20130907125651.M43356 at bartsplace.net>
> > Content-Type: text/plain;	charset=iso-8859-1
> >
> > On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote
> 
> > 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.
> 
> Technically, this isn't true... because all languages describe their
> own details. So, as long as it meets the basic definition, it's all
> gold. Still, this would be the easiest (and very possibly best)
> option, and is one of the two that C++11 provides.

Well, its more a matter of what the goal of such would be to begin with. If
that is to provide easier porting to dgd for current mudos/fluffos based
mudlibs then what those do define the details initially.

> 
> > 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.
> >
> 
> I forget, do mappings stay shared after DGD finishes a particular
> task?

Not when passed to a different object.

> If not then a simple "mapping container" that overrides the []
> operator would presumably do the job perfectly well.

Not when passed to a different object, your container will be an lwo if you
want the operator override, and won't stay shared after the task finishes.
Make it a real object, and you wont have this problem, but you won't have
operator overloading, and will need to explicitly get rid of it when its no
longer referenced by anyone.

As long as things stay within the same object, its all fine.

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