# [APROG] local

Michael Brundage (anomaly@u.washington.edu)
Fri, 1 Dec 1995 19:08:04 PST

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

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

    Okay, but I still say you should do it in-db with $local:object(name)
    instead of with some server hack to handle &local references (which will have
    the effect of making your core less portable, not more).  If you set
    $local:object(name) to return $list_utils:assoc(this.local_objects,args[1])[2];
    (in the representation you posted, at least) then you'll be done, poof,
    just like that, without the need for any strange server mods.

    If you want to distinguish between fun local objs and core local objs, then
    you could still have $local:object(name) return the object reference, but
    now you could store objects in both $local.fun_objects and $local.core_objects
    Now change the verb above to be return $list_utils:assoc({@this.core_objects
    ,@this.fun_objects}, args[1])[2]; and you're still done, and now your
    corification verbs can just look at $local.core_objects, or whatever.
    And then if later you decide to have fun local objects, core local objects,
    and purple local objects, you could do ....

    You get the idea.  I really think server hacks should only be made to
    (1) add missing functionality or (2) seriously increase efficiency.  For
    example, FUP provides functionality that would be otherwise difficult
    to implement purely in-db [though even then you can get by with
    open_network_connection() and an external script, but that's about an equal
    amount of work and possibly less secure].  Also, I wouldn't implement a
    regexp package in-db -- that'd be pretty slow -- hence builtin functions
    such as match()/rmatch() to do it for me.  But this &local_object_name
    syntax wouldn't add functionality and wouldn't be significantly faster
    than the slightly more bulky $local:object(name).

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

    Why not just use the simple verb above?  It's both more flexible and more
    compatible with existing MOOs, IMHO.  And it doesn't make assumptions about
    the database (for example, what if $local doesn't even exist?  What will
    &foobar evaluate to then, E_INVIND or something?)

    But then, I also wish that the server called $server_options:option_name()
    instead of accessing $server_options.option_name directly, since then one
    could (for example) checkpoint infrequently during the day and more
    frequently at night, simply by having $server_options:dump_interval()
    calculate the time of day and return the value you want.

    michael