[DGD] Recompiling inherited objects

[Noah Gibbs]

--- Petter Nystr|m <md1pette at mdstud.chalmers.se>
wrote:
> I have an issue with recompiling inherited code. The
> simplified scenario
> is this:
> 
> Program A inherits program B. Now I wish to
> recompile B and have A and all
> clones of A to use the new code aswell.

  Yes.  In Kernel Library (or Phantasmal, which uses
the Kernel) terms, A is a cloneable object, and B is a
library object that it uses.  There are several other
things you can call them, but I'll stick with
"cloneable" and "library" for this email :-)

  You can find some of this explained here: 
"http://phantasmal.sf.net/DGD/Kernel/Inheritance.html"

> It has come to my understanding that this is
> possible with DGD, but that
> you have to do some of the work in your LPC lib. If
> I have got this right,
> the kernel lib aswell as Phantasmal provides public
> code that does what I
> want.

  The two together do.  The Kernel Library makes the
cloneable/library abstraction (which doesn't exist in
core DGD), and Phantasmal automates some of the
rebuilding.  For finer-grained rebuilding, there's
also an Object Manager written by Geir Harald Hansen
that will do what you want.  I like mine better, but I
would :-)

> So my
> question is: In general terms, what do I need in
> order to do accomplish
> this?

  First and foremost, you need to handle the various
notifications that the DGD server gives you about
things being compiled and recompiled.  The Kernel
Library will take all of those notifications and send
them to an Object Manager.  If you don't use the
Kernel Library, though, you'll need to get them some
other way.

  Those notifications are named things like compile()
and include(), and you can find them in the DGD
server's documentation.  Or you can see how the Kernel
Library handles them, and use that code for
documentation.  The DRIVER object
('/kernel/obj/driver.c' for the Kernel Library, I
think) receives all of them originally.

> My initial plan for solving the problem was this:
> For each object that is
> inherited I keep a list of the program-names
> (masters only) that inherit
> that object. I do this through the inherit_program()
> function in the
> driver object.

  This works.  You probably want to make sure that the
list is properly protected so that subclasses can't
fake this information and break your security.  Or you
could use the Kernel Library, which already does that.

> When I compile an existing program
> that according to my
> data-mapping is inherited by other objects, I go
> ahead and outright
> destruct every master object with the names stored
> in my mapping. When
> done and compiled, I can compile all the objects I
> had to destruct in
> order to allow the desired recompilation.

  I would check that you need to destruct it first. 
Doing this every time you recompile can take a *lot*
of time.  And remember, long compiles will start to
overrun your timeslices.  That is, if you put them
inside an rlimit() statement, they'll start taking too
long and failing.

  You can solve that by not putting them in an
rlimit() statement, so they can take as long as they
want.  But remember, that can be a long, long time and
you want your MUD to be interactive...

> This executes without errors, however, it does not
> have the desired
> effect. Do I understand it right if I think that the
> problem is that all
> the clones of the masters that inherit the code in
> question have their
> link to the original source code severed when their
> master is destructed?
> When I compile the source again, the clones of the
> old masters are not
> updated.

  The clones keep a connection to the old masters and
the old code.  You could change that by destructing
and recompiling, but then you'd lose all the data in
all the clones and have to make them again.  Not good!

  So instead, what you could do is make sure that a
class can either be inherited from, or cloned from,
but not both.  Then you could recompile the parent
class (after destructing it), but it would have no
direct clones.  Then you could recompile the child
classes to give them the new code.

  I'll admit that I don't fully understand the whys
and wherefores of all this stuff.  I only know that
the Kernel MUDLib's approach works well.  I think
duplicating it yourself would be silly because it's a
lot of work and the Kernel MUDLib already exists. 
Maybe you could start with the Kernel and make a
stripped-down version?

> What I wonder then is: Is the solution now to also
> keep a list of all clones
> that inherit a certain  program, and when the new
> master has been
> compiled also recompile everyone of the old clones!?
> This seems a bit
> heavy to me and I am not sure it would work.

  Hmm.  I'm not sure you can recompile a clone
specifically.  I think you can only recompile the
object it was cloned from.  So you couldn't do this.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd