MOO-cows Mailing List Archive

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

Re: [APROG] local



At 21:06 12/1/95, Michael Brundage wrote:
>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)?

I would like to do that too. (Well in fact I already did it for verbs.)
IMHO this kind of information should be on the object, not on $local.
As well as all the information related to the object status...

$local should be an effective way to retrieve the object... then you would
have to check the properties, or better, a verb on the object that would
give you the information you need. (Like has this object been modified
since the last time I updated/ported/backuped it)

>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.

My primary concern is to be able to write code with &local_core_obj
refernces in it. Why ? because I'm working on a core and I want to make a
difference between the local-core objects I use for fun/developement/...
and the core objects I want to have when I will make-core-db.

Of course there is a wider use for &local_core_obj refrences (like
autoport... and maintaining a distributed MOO db ?)

>[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.]

Of course, if you don't like $prop... you will not like &local :-)

Janus




Follow-Ups:

Home | Subject Index | Thread Index