[DGD] Failed Inheritance and Object Daemon

[Noah Gibbs]

  That's the sort of case that's the reason that my ObjectD and Geir Harald
Hansen's both keep multiple issues around.  Though yeah, it can get a little
complicated.

  You can use atomic functions to prevent this problem, but it'll only work up
to a certain number of objects - beyond that, having to swap in a whole bunch
of objects gets too slow, or bigger than available memory.

--- Steve Wooster <swdgd at intergate.com> wrote:

> I've been thinking about ways of setting up an object daemon, and previous
> ideas of 
> mine have been overly complicated, so I've always had trouble starting them, 
> especially since it seemed like I'd always come up with some sort special
> case I 
> didn't know how to handle. My brother suggested the K.I.S.S rule, pointing
> out that I 
> can assume regular statedump backups and a testmud. So I figured I'd just
> have all 
> objects up-to-date all the time. But I've never been too sure of the best way
> to handle 
> the following situation... Let's say I have some standard library object A,
> and a group 
> of coders/builders makes their own library object B which inherits A and
> defines 
> foobar(). Assume there's numerous objects inheriting B. Now let's say I don't
> know 
> about B, and I add foobar() to A, and make it nomask, then try to update it.
> After 
> updating A, the mud tries to update B, but gets a compile error due to
> conflicting 
> functions. There's only two ways I can think to handle that...
> 
> 1. I can't update the objects inheriting B, so unless I destroy them all,
> they'll all be 
> using an out-of-date version of A's code. But I want to keep everything
> up-to-date at 
> all times, so I destroy B and everything inheriting it (perhaps deleting a
> significant 
> portion of the mud) and give a list of object types destroyed.
> 
> 2. Revert to the previous version of A's code and fail to update it. I think
> this would 
> either be innefficient or require a lot more work for me.
> 
> I'm leaning towards option 1, because it's much simpler and requires less
> code, and I 
> figure the admins would probably do backups before updating any major part of
> the 
> mudlib, and at least test it out on a testmud. Does this sound reasonable?
> (keep in 
> mind that this means if the OBJECT inheritable fails to compile, the entire
> mud 
> vansihes without a trace... but hey, there's backups and a testmud, right?)
> Does 
> anybody have any other ways of doing it? Any ideas/opinions are much
> appreciated!
> 
> -Steve Wooster
> 
> PS, this is mostly a learning experience... I don't expect to have a mud
> running any 
> time soon, so there's no need to point out that making your own object daemon
> is 
> riddled with pitfalls.
> 
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd
> 





		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs