# [APROG] $local

Michael Brundage (anomaly@u.washington.edu)
Fri, 1 Dec 1995 17:42:11 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > 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