MOO-cows Mailing List Archive
A new core concept...
Date: Sun, 31 Mar 1996 23:31:00 PST
From: Ron Stanions <firstname.lastname@example.org>
Content-Type: text/plain; charset="us-ascii"
The ideas mentioned with verbing properties had some interesting angles, but as was also
mentioned, you can accomplish the same thing by making properties !r and creating verbs with
the same name.
Anyway, one of the things that has bothered me about the current MOO core since day one is
'too many wizards ...'. anyone with a wizard bit can /still/ do everything to everything, and when
you have more than one person being a wizard, you end up with a lot of unclean core and verbs
that operate with different syntaxes, and ... you get the idea.
Well, I've been working on a different approach with a core I was working on, (but pretty much
shelved for the time being, lack of time and a number of other things...) This core works on the
concept of only having one true wizard. There are other wizards, per se, but they don't have the
ability to access everything. In fact, all objects from #0 to #100 are protected against any form
of editing except by the one with the wizard bit. (You /can/ have more ArchWizards but it would be
Players get their wizard or builder or programmer access by being given a feature. This allows
for a form of multiple inheritance, where you can have programmers who aren't builders, etc...
This would also make it easier to create character classes or types for gaming systems that
want to do that kind of thing, (maybe).
Every object must be a child of #1. With this rule, most of the things scattered through the
$XYZ_utils classes got moved to #1 so everything inherited them. Now, instead of using
$object_utils:isa(this, that), you can just use this:isa(that) (which reads much better too. :)
This also allowed me to enforce certain rules. recycle() for example, can only be done
by calling this:recycle() or by pass()'ing from within a recycle verb. If people create a
recycle verb on the object that doesn't pass(), the object doesn't get recycled, so it helps
to force the requirement this way. recycle is very smart about nearly everything in the
#0 to #100 object range. any 'core' objects and properties won't be left dangling. features
get disconnected through the same mechanism, etc, etc... even.
The programmer's bit simply never gets set or used. If you have the programmer feature
you have everything you need, and without the programmer's bit (and now with the new
switch in 1.8.0 that allows you to protect .program) you can't create/edit/delete verbs
or properties or anything without going through the proper channels. Even wizards are
forced to abide by this.
The lock syntax has been expanded to allow verb calls and a much more english oriented
structure, full parenthesizing, and the ability to 'deparse' a parsed lock back into its english
language. Further, locks are what are used to define most of the controls in the system. EG
instead of just declaring an object or exit visible or invisible, you define a lock on it so
that perhaps only people with the red golfball can see the secret door, etc...) All locks work
on an isa() principal too, and check against the player, his features, and what he holds, so
again with creature classes you can lock against them having a certain feature or class of
features as well.)
Rooms are of the exitless variety but lose no functionality over the current room system,
though that system isn't entirely complete as of yet.
Every single verb and library call has been rewritten from square one. Many of them do the
same things as the good old Lambacore, but nearly all of them are enhanced to do something
more, or better, or faster.
There are no $XYZ_utils classes, there is only $lib. There is actually very few verbs currently
on $lib, but then again, there is much much more that needs to be done to this core, as it
stands it allows building,
I've forgotten a great deal about what I put into this core already beyond these few finer points.
At any rate I thought I'd toss this out here and just see what kind of discussion it creates. :)
email@example.com -- Site admin for clawpaw.com http://www.clawpaw.com
Chaeon - Site Wiz or K'ryn - Bronze rider, VirtuaPern Moo http://www.clawpaw.com/VirtuaPern
VirtuaPern MOO - telnet dragon.clawpaw.com port 9999
Subject Index |