MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: [APROG] $local



> 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.  This would be a standard object, updated 
> regularly, that maintained a listing of the `regular' generics and their 
> local object numbers.  This `registry' of sorts could also act as a way 
> of tracking the aforementioned database modules.
[...]
> To port something using Autoport Utilities, you'd provide a keyword 
> (prefixed with &) and the utilities object would do the lookup.  Example:

And what if I decide I want to not only keep track of the names and obj_nums,
but also the date the object was last modified (to make maintainence a smaller
headache)?  It's a fine idea to encourage some sort of systematization
of $local.objects, and obviously you can just write the autoport code to
use that, and then if people want to use autoport, they will need to
keep $local.objects current.

However, you shouldn't blur the separation between this information which you
wish to maintain, and the method you use to maintain it.  In particular, I
see absolutely no need to modify the server to recognize some new
&local_obj_name  {:= $list_utils:assoc($local.local_objects, name)[2]} syntax
when you can achieve the same thing in-db with something like
$local:local_object(name); which could then handle the lookup.

[For that matter, the same things could be said about the $prop {:= #0.prop}
syntax, but we seem to be stuck with it -- which is why length(properties(#0))
is about the age of the universe on some MOOs and one is prevented from
switching to a more efficient data representation for `named' objects.]

michael

anomaly@u.washington.edu


Follow-Ups: References:

Home | Subject Index | Thread Index