[DGD] Leaf objects

[bart at wotf.org]

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/