[DGD] Re: Strange clone_object behaviour

[Kris Van Hees]

On Mon, Sep 14, 1998 at 12:25:43PM +0000, Frank Schmidt wrote:
> The main idea is that it requires mudlib code ontop of it, I haven't said
> anything else. But the kernel lib is far from what I see 'fit' for MUD
> programmers world wide, when lacking lots of "general" functionality to
> handle arrays, strings, mappings, math, sorting algorithms, etc, etc,
> which in my opinion belongs in the auto object. (Previous mailinglists
> explains why) And that's just one of the issues, each time you need
> something special (which you know DGD can offer), a General kernel lib
> will probably not support it.

I fail to see why what you call "general functionality" should be placed
in the auto-object.  While it is definitely possible (and very useful when
emulating other drivers, etc), it doesn't look right in view of the design
that is shown in DGD itself.  Putting a huge auto-object on top of a fairly
minimalistic driver sounds weird to me.

When the goal is to have a pretty much DGD native mudlib, rather than trying
to emulate another driver, I'd expect that proper object oriented design of
the core is important (plus it is very convenient).  In that sense, I would
actually expect to see that things like specific string, array or mapping
handling (and others) are provided through inheritable classes.  Surely not
every class in the mud requires a sorting algorithm?
> 
> The most serious mudlib programmer will (in my mind) disregard the kernel
> lib, and rather build the mudlib on a base more suited for creating MUD
> worlds, WITH the unlimities of DGD. Too bad there aren't lots
> of them around. My choice of driver is however DGD, DGD, DGD and DGD.

Actually, I think the most serious mudlib programmer takes DGD, and starts
from scratch, building his or her own core mudlib, and work up from there.

Aedil



List config page:  http://list.imaginary.com/mailman/listinfo/dgd