[DGD] Re: Kernel library

[Felix A. Croes]

Frank Schmidt <franks at colargol.tihlde.hist.no> wrote:

> I have too low system response to answer more briefly.
>
> But let me explain: I see the world from an LP-programmers view. When
> creating LP muds (or any text mud), the programming techniques does not
> have to be perfect. In fact, forcing wizards to type "inherit class A" and
> "inherit class B", each time they have need for a little function, will
> make them very frustrated. As a wizard myself, I have many times over seen
> the big advantage (in productivity and simplicity) of not having to
> #include and inherit a dozen files just to make an object. That's one of
> the things that have attracted me to code more in LPC rather than C++.
> Simplicity with regards for the actual users (you know, that dude you just
> taught LPC ;). It is an advantage for a beginner, and for
> high-productivity experts. (Damn, response time of 10 seconds for each
> keystroke!) 

But not all LPmuds are like that.  There are LPmuds without wizards
and just one administrator.  There are LPmuds, like Genesis and
Xyllomer and all the others that are CDlib-based, where you <do>
need to include and inherit many things to make an object and where
the required wizard skills are correspondingly higher; and those
are pretty decent muds.  There is LPMOO; wouldn't it be nice to
write such a mud, where the wizards use only a higher-level
programming language, in the cleanest possible LPC code?  Then
there are all the possible muds that might be written in LPC,
including graphical muds like Ultima Online and Asheron's Call.

I understand the appeal that the simple mud has for you, but that is
only a small, and shrinking, corner of the LPmud universe.  As far
as I am concerned, the 2.4.5 mudlib meets the requirements of this
simple mud pretty well.  For the sort of mud that is to be built on
top of the kernel library, I had something more ambitious in mind.


> Also, the inherit system with class libraries is confusing: Let's say you
> have a StringClass library inherited by A. Then A is inherited by B. And
> then B gets the StringClass library for "free". In other words: The
> StringClass library _should_ have been inherited privately to A, since it
> is only meant to be used internally in A. And if you implement
> private/protected inheritance, explain _that_ to the newbie wizard. ;)

This is a valid complaint.  I will consider adding private inheritance
to DGD.

Dworkin