# [APROG] local

Michael Brundage (anomaly@u.washington.edu)
Fri, 1 Dec 1995 21:18:22 PST

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

    > 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