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

# Re: [APROG] local

- Date: Fri, 1 Dec 1995 18:35:21 PST
- From:
- Cc: " (Bill Garrett)" <bill@yeehaw.com>, moo-cows@parc.xerox.com
- Content-Type: text/plain; charset="us-ascii"

    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:

- Re: [APROG] local

- From: Michael Brundage <anomaly@u.washington.edu>

- Prev: Re: [APROG] $local (was Re: Suggestion, re: Minimal.db)
- Next: Re: [APROG] local
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index