MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: The History Of Frobs, Part Zero (was Re: Use for $call_verb)

OK, I think I get the idea of what you are calling 
"Inexpensive" when you talk about your heart Frobs, and so on....

So here's an alternate viewpoint taken from my as yet unseen Mod1 of
NewCore, (Unseen because it is Unimplimented)

Essentially, I wanted inexpensive verbs and properties.

Because MOO uses Objects to store Verbs and Properties, my concept was
to place inexpensive verbs and properties, in "Gathering Objects" I called
"Database" objects, "library" objects, and "Characteristic" Objects.

When designing Data and Methods that were to work together as a single
lightweight object, I decided to attempt to code using Objecules, or
Sorted Objects with label verbs and properties that allowed the separation
of different functions within a holding object.

The next trick was to blur the distinction between different Objecules
and thier verbs, by making it possible to alias the verbs, as well as the
objects, and therefore to allow overloading of a verb, or calling of an
object as if it were an object:verb call, and getting the right verb.

(The idea of all this, is to simplify the language interface by making
the computer do more work)

By basing all "Gathering Objects" on a basic "Database" prototype, I
hoped to be able to achieve user defined definitions, in-db.

The concept was that the base class, would be a DATABASE, with
user defineable fields, and types, which would be then interpreted
by a special interpretive method, into output lists in the proper
order.

Since Verbs and Objects would then be considered a special case of
Property, (containing a link rather than the actual object/verb etc)
there would be no problem building special function Objects from a
sort of generally accessible library of Verbs and Properties, or of
changing whole lists of properties, with the change of a single environment
parameter.

The idea being that instead of Customizing the Users Object, and adding
"Feature Objects" to it, you could customize a list of features and 
Characteristics from central databases, or create your own unique lightweight
lists of characteristics and add them to the central database for others
to enjoy, or keep within your own area, so that others couldn't "borrow"
it without permission.

Another place I thought this would be useful, is in the development of
"Cheap" Maps, where a common theme, and set of characteristics could be
carried among a list of "Locations", or where movement within the same
room, could be connected with different views of the objects, allowing
the user to turn, and "Walk Around" and object, without inflating the
Object Value too quickly. 

One place I thought of using this type of stuff, was in my "MALL" and
"Park" concepts where I had been forced to define Multiple objects just
to allow different features to be available from different "Locations"
and through different "Paths".

It made no sense to me, to have to define a relatively small "Park" with
minor themes that you could traverse in any direction, as a list of
almost as many objects as there were features I wanted you to "happen"
upon.

I found it difficult to deal with Hallways that limited me to 4 or so doors
and Streets that had to be defined, one building at a time.

It made much more sense, to allow the exits to be defined off of a generic
but extended street object, that you entered, at some point, and exited at
some point,  but not always the same point. In between, you would still
be on the same street, but would "Travel" along it, seeing the sights.

The neat thing about this approach, I thought, was the ability to build
mappings of mappings, into each other, so that they inherited a heirarchy
of location. Thus the Main "Location" Object, could have within it a 
mapping of "Planets", a mapping of continents on each planet, a mapping of
countries on each continent, and so on, gradually reducing to street
addresses, and individual buildings/rooms, or locations within the same room
and through a form of inverse inheritance probably based on database search
routines, that used object queries, a person could be located to within
a specific room, so that you could "Drop In" on him unannounced....

(At least at the WIZARD level)

Of course, I had planned to do this at the "In-Db" level, but if someone
wants to impliment a similar system at the Server Level, they are certainly
welcome to.

				GREY

GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca 
YMCA Edmonton             
(Back on line!>
References:
Home | Subject Index | Thread Index