[DGD] Leaf objects

[bart at wotf.org]

Not if they do not at all want to make use of persistence. Note that in the
'classic' lpmud world, this restriction is highly unusual, rather, using
things from '/std' both as clonable and inheritable is rather the norm there.
Yes, it means a dest/reclone cycle, this has disadvantages, but it still is a
choice one can make.

For Way of the Force (which has its roots in a highly modified lpmud 2.4.5
derivate) it took a pretty serious effort to kill all the cases of double use,
and there is still some code in there that traps such use and informs me about
it. Don't think I've seen any new cases since the start of my current game
world (about 7 years ago), but it has taken many years to find and address all
cases (thanks to a somewhat substantial codebase with some rather obscure bits)

Getting this right from day 1, and making totally sure it stays right is the
way to go if you want persistence, doing it later on is a real PITA, through
it is possible. But, not using persistence is a choice. Not one I personally
would make, but its certainly a valid one.

The world is not black/white, and ignoring the subtle things that cause it to
not be black/white isn't making things more clear, its making sure important
things won't be noticed :-)

Bart.

On Tue, 28 Jul 2015 02:55:30 -0700, Raymond Jennings wrote
> I think all dgd mudlibs should enforce this "you can either inherit 
> it, or clone/call/lwo it, but not both"
> 
> On Tue, Jul 28, 2015 at 1:54 AM, <bart at wotf.org> wrote:
> 
> > Kent,
> >
> > Note that the gurbalib kernel you use
> > enforces the same rule (can't clone an
> > inheritable and can't inherit a clonable).
> > It doesn't have the nice solution of
> > auromatically generating a clonable in such
> > a case through that wouldn't be too
> > difficult.
> >
> > On gurbalib those restrictions are in
> > compiler_d in allow_inherit and
> > allow_object. Felix'explanation tells why
> > this is important, and why those
> > restrictions should be left in place and
> > enforced very strictly. You will *NOT* be
> > able to support runnong dgd as a persistent
> > server without enforcing those rules as you
> > won't be able to recompile things without
> > losing data and state.
> > Along the same lines, you should make sure
> > all your changes can be handled by the
> > warmboot and rebuild commands.
> >
> > Bart
> >
> > On Mon, 27 Jul 2015 13:27:47 +0200, Felix A.
> > Croes wrote
> > > Blain <blain20 at gmail.com> wrote:
> > >
> > > > I noticed in your cloud server you use
> > leaf objects for cloning.  May I ask
> > > > what the benefit of this is?
> > >
> > > To explain, a leaf object is an object
> > which is not inherited by any
> > > other, and the cloud server lib
> > automatically generates a leaf object
> > > when you are trying to clone from a /lib/
> > object, and clones from
> > > that instead.  The purpose is to ensure
> > that no object you clone
> > > from is inherited by any other, while
> > allowing one to clone from a
> > > /lib/ object as a shortcut.
> > >
> > > Objects that can be inherited should never
> > be used to clone from, since
> > > that prevents the clones from being
> > upgraded.  An inherited object
> > > can only be upgraded by first destructing
> > and then recompiling it,
> > > while a leaf object can be recompiled in
> > place, without destructing
> > > it; this will also upgrade all clones of
> > the leaf object.
> > >
> > > Regards,
> > > Felix Croes
> > >
> > ____________________________________________
> > >
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > 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/