MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: [APROG] $local (was Re: Suggestion, re: Minimal.db)
GRAEME SMITH email: grysmith@freenet.edmonton.ab.ca
2536 138A ave Edmonton
On Fri, 1 Dec 1995, Bill Garrett wrote:
> I'm actually looking at Mr. Smith's module proposal, and wondering if the
> MOO world at large would be willing to accept the existence of
> $local.local_objects.
Thank you for looking at my proposal.
The reason I am starting at base 0 (or Mod 0) with this plan, is that my
frustration stems from the nature of the current MOO Core, and I am not
sophisticated enough, at MOOCoding to be able to extract enough of the code
without sufficient reworking to be able to use the existing core.
If the Community adopts new standards of MOOdularity, as a result of my
work, it does not really matter whether or not NewCore Fly's on its own.
I won't abandon it, myself, if only because It is a learning experience
figuring out how to get around the Breaking of Modularity caused by add-hoc
design.
I think that NewCore, will emerge as an alternative to the Standard Core
for those interested in a little more flexibility due either to memory
restraints, or alternately to those interested in building unique MOO's
for unique applications. To that end, I am trying to pare it down to its
essentials first, then make it powerful by extension.
Just as the 700 line verb @autoport, is turning into the Object
Autoport Utilities, sets of objects such as the basic Sysop Package
can be formed into modules, (Mod0) from the current core. There is no
question, at this time of compatibility between NewCore and the present
Cores such as JHCore, and LambdaCore, quite simply they aren't compatible
they are meant as alternate approaches. So, when you consider Modularity
in the Larger Cores, Start Simple and just add a new object as a generic
Module, then develop an object called $local to track them.
Further Feedback on my Mod0 proposal is requested.
References:
Home |
Subject Index |
Thread Index