Re: [APROG] local

• Date: Fri, 1 Dec 1995 19:08:04 PST
• From:
  Michael Brundage <anomaly@u.washington.edu>
• Cc: moo-cows@parc.xerox.com
• Content-Length: 2726
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <v02130503ace568dd751a@[204.50.77.21]> from "Richard Godard" at Dec 1, 95 09:35:21 pm

> 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

• [APROG] local
• From: Judy Anderson <yduj@cs.stanford.edu>

• Re: [APROG] local
• From: rgodard@divsun.unige.ch (Richard Godard)

• Prev: Re: [APROG] local
• Next: Re: [APROG] local
• Index: MOO-cows
• Thread: MOO-cows