[DGD] Failed Inheritance and Object Daemon

[Steve Wooster]

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.