MOO-cows Mailing List Archive


Re: [APROG] local

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

Hmmmms it seems there is some big misunderstanding.

I *never* spoke about a server hack. All what I said can be done in-db by
making set_verb_code(), verb_code() and eval() wiz only and enforcing the
programmers to use, example, $compiler:set_verb_code(),
$compiler:verb_code(), $compiler:eval(), that would do all the adequates

Since those substitution will be done by regexp matching, that's why I
asked if some regexp wiz were interested (and some are :-)

BTW I don't want $list_utils:assoc(this.local_objects,args[1])[2]. I prefer
the $ approach... of course it can lead to a zillion of
properties object.

What is done at E_MOO is to have $core_refs == {"$sys", "$player", ... }
and $core_objs == {#0, #6, ... }... those list are updated when requested
or when a new object is corified (and I guess when a prop on #0  is
deleted). I think it's faster and easier to maintain than the way that lead
to use $list_utils:assoc.

>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?)

BTW if $local doesn't exist $local:object(name) will not help you more than
&name reference :-)
In this case I don't think the verb approach is more flexible.

I like to be able to type $player_class:(verb)(@args)... what I would like
now is to be able to wrtie code with &frands_player_class:(verb)(@args)...


Home | Subject Index | Thread Index