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