[DGD] Re: Strange clone_object behaviour

[Frank Schmidt]

On Mon, 14 Sep 1998, Par Winzell wrote:

> I don't understand what you are saying. You seem to feel the need for a
> kernel library, and the way you state it, your urge seems to be a
> healthy one, for exactly the kind of abstraction layer that the kernel
> library does provide.

I think we both agree here, when mentioning all those "features" I was
making an ironical joke/point. One needs an abstraction layer between the
driver and the actual mudlib, especially in DGD.

> 
> Of course it's perfectly OK if you do not like the DGD-supplied kernel
> lib, but how exactly do you envision a dependable abstraction layer to
> function if it does not require mudlib code to be built on top of it? If
> it does not use auto/kernel object functionality? The entire point of
> such a thing is to sit solidly between your torches and AI-monsters on
> one hand and DGD on the other.

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.

> The kernel lib isn't perfect for my needs either; infact, if I were to
> write a lib at this point I'm still unsure whether I'd use it or not.
> But your logical makes little sense to me. Are you perhaps actually
> talking about wanting a rich, gooey, high-level toolbox thing?

Nonono, as small as possible of course. But I think if one starts on the
Road of Generality, in this issue, you will never satisfy MUD
users/programmers.

> And really, that bit about "with all respect", etc, what the hell is
> really the point of that? Dworkin's competence as a mud-driver coder is
> about as far from being in question as it is possible for one thing to
> be from another. It is certainly not a very good foundation from which

Did I question Dworkins competence as a mud-driver coder? When/where?

> to launch a comparison as regards his kernel-lib-writing skills, and I
> don't understand why you feel the need to make it.

It just doesn't match with my view of a base for MUDs. Now, why are _you_
so offended?

> Use the kernel lib or don't use it, comment on its applicability to your
> problem or its lack thereof -- but I think you are simply out of your
> depth attempting to pass some sort of objective judgement on its
> qualities.

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.


Frank Schmidt
(If I am unclear, bear in my it takes 1-4 seconds from my input reaches my
pine process and back...)




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