Re: [APROG] local

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

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

Ahh.  I understood you to mean you wanted to have a server-recognized syntax.
Sorry to beat a dead cow and put it in everyone's mail box, but
I just gotta respond:

> 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 $local.name 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.

Okay, whatever.  Obviously you'll do it whatever way you want; having gobs
of properties on $local v. maintaining two lists v. maintaining an
associated list will be a matter of personal preference in any case.  My
main objection was to introduce a server mod to handle a syntax I consider
to be of questionable use.  The reason I thought you were talking about a
server mod is that it will be impossible to simply perform regular expression
matches if the syntax is going to handle anything other than direct
references.  That is, the meaning of
     names = {"sys","player","foo","bar"};
     object = &names[5];
or
     &("foo"+bar+baz);

cannot be determined by a simple (or complicated) regular-expression match.

However, they would be handled easily (and more efficiently) by list
operations.  If you don't want to keep two lists like the E_MOO system
you described or an associated list as I described, then you could always 
have $local:object(name) perform
   props = properties(this);
   return props[args[1] in props];
which would give you the gobs of property names you want, but still be
flexible enough to handle computed local object names.
    
Moreover, performing regexp substitutions will erase the &syntax in the verb
code and replace it with something else (God forbid you should be thinking
of putting in direct object number references, since that would be completely
not portable) so that the next time you decide to edit the verb, the
&name will be gone.  Or were you thinking of performing a second regexp
substitution when the user accesses the code, by searching through all the
known $local objects whenever a direct object reference is encountered,
and if found then replacing #777 with &my_local_object, etc.?  In that case,
you'll be performing gobs of substitutions, and in nice places too, like
for-loops and strings.  This is a terrible idea, IMNSHO.

So, this is why I mistakenly thought you were proposing a server modification,
so the &name could be stored in the database.

> 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 brought this up because I was thinking of the server hack, and you would
need the server to assume the existence of $local to be able to decipher
the &name syntax in verb code, and I think adding unnecessary server
assumptions about the database is not a good idea.

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

I understand this, and your method would certainly produce neat-looking
code (provided one knew what &name did) -- except that it won't be stored
that way anyhow.  On the other hand, you could just do
$local.frands_player_class which is just as readable, or even
something like $local.player_class.frands so that then you can have
similar-looking syntax for $local.player_class.his and
$local.player_class.hers and $local.player_class.theirs.


michael

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

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