[DGD] Re: Kernel library
E. Harte
harte at xs4all.nl
Tue Sep 15 12:26:43 CEST 1998
On Tue, 15 Sep 1998, Frank Schmidt wrote:
[...]
> 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.
Why, because then they are forced to realize they are using something that
is actually rather special and it's nice to have it in a prefab library
that they can just 'inherit "/lib/arrays";' or so and use? Other than a
slightly longer learning period I don't see what the problem is. You
don't go teaching newbie-wizards about sort_array() on their first day, do
you? I hope you start with explaining what a function is, hell, what an
object is, perhaps what variables are, function-arguments, but not
something complicated like control-structures, if-statements,
function-calls that require more than a simple one or two arguments... :)
[...]
> 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. ;)
I don't see what's confusing about that? If you create a box that happens
to need a ball inside it to make it work, you get the ball along with the
box, the ball doesn't suddenly disappear when you use the box for
something else? Of course, 99% of the time you can happily ignore and
forget that the ball is there, b/c it isn't in the way of other things. :)
> Think of the REAL users of the system (not just the admins with advanced
> programming skills, but little productivity). There are the players; who
> just doesn't care _how_ the game is programmed as long as it's fun to
> play. Then there are the creators; who just want to see their fantasies
> come true and the players to play through them.
And then there are the admins that are there to make sure the creators
have a nice extensive set of base-objects to build those fantasies from,
and 99% of the time that's all they're going to need, except in that 1%
occasion when they need to stop and think:
'Oh right, which lib had that extra bit of functionality again?'
Big deal?
> You can make as much advanced programming environment as you like, but is
> it elegant to program in? Or does it require "HUGE" know-how and lots of
> extra code to specify this-and-that, programming language specific things
> that really has no impact on the end result, just takes longer time and
> more frustration to code. "And the OO design is beautiful." Who cares; in
> the MUD community?
A lot more people than you obviously realize. :-)
> I know I'm being maybe a bit too realistic.
You misspelled 'pessimistic'. Hope that helps.
[...]
> (This is my point of view with a tea-spoon, sorry for lengthy note. You
> are entitled to have quite a different point of view. I'll respect yours
> as long as you respect mine.)
Ditto.
> Felix:
> The kernel library is fine, you have spent alot of good work into it. It
> is the general usefulness (in practice) I am questioning. The main point
> go like this: If I am to make a mudlib, I'd want the full control of
> access, users, driver object, auto object etc, etc. If a kernel library
> can give me this, fine, but I haven't seen such a lib yet.
Then you haven't looked closely enough at the kernel-lib. You can
redefine just about anything, there is support for a mudlib-only
auto-object, there are hooks in the driver object that allow you to run
your own show entirely while still having the kernel-lib track your
resources for you. I guess what would convince you would be if someone
was fool enough to build a 2.4.5 emulation on top of the kernel-lib, just
to show that it can be done? Alas, I for one won't waste my time on such
a horrible concept. :-)
[...]
Hope I didn't sound too pissed off, it's just a shame to see a good piece
of code being considered inadequate or inappropriat just because someone
doesn't realize what is possible to do with it.
Erwin.
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list