# [APROG] local (long)

Richard Godard (rgodard@divsun.unige.ch)
Sat, 2 Dec 1995 18:42:59 PST

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

    Here is a little summary of my (and some other people) thought as well as
    some problems, solutions and possibility of the various use of $local.

    Please, wizards, let me know if you think you would be interested by that
    use of $local. Answer to me privately (rgodard@divsun.unige.ch) and tell me
    [yes/no], the name of your MOO. I just would like to see if some standard
    can be established or if it is foolish. I can summary the result of this
    'poll' to the moo-cows later.

    Here we go...

    First thoughts:
    Having a prefix (further & will be used but it can be any other char) that
    would have the same functionality/suntax than the $ prefix, except that:
    1) &prop would be searched as $local.prop, while $prop is searched as #0.prop
    2) &prop references would not be incorporated in core made by the use of
    the mdb command.
    3) the support for the & prefix would be done in-db, a direct consequence
    of this is 4
    4) the code stored effectively in the db is $local.prop not &prop
    5) the right to make & references (further called local-core ref or local
    ref) may not be limited to wizards (thought it can be limited to wiz if you
    want to... depends how you plan to use it)

    How to implement it?
    1) change the object matching... a really little hack on
    $string_utils:literal_object allow you to have the matching of &prop
    available for most commands and verbs.
    2) On $server_options, protect the set_verb_code, verb_code and eval
    built-in function, making them wiz-only. Enforce the programmers call those
    functions through verbs. The verbs would do the perms checking and the code
    substitution:
      a) to replace the &prop ref by $local.prop in the eval and set_verb_code
    verbs before calling the built-in function.
      b) to replace $local.prop by &prop in verb_code after calling the
    built-in function.
    note: &prop should NOT be replaced by an obj#, since that's what we try to
    avoid.
    3) A @local-corify <obj> as <name> verb on whatever player class you want
    its kids to be able to local-corify objects.

    Advantages:
    1) cleaner code and database (remove the need to have zillions of core
    object and allow non-wzards not to rely on hardcoded object number)
    2) Cleaner core generation. During the core db generation, you can enhance
    the code of mdb to check if there is any dependancy of your core objects on
    local-core objects... and maybe have an option to corify them on-the-fly...
    3) more portable/distributable code...
    e.g. if some code relly on &quinn_utils to perform some task, when you port
    it, if the MOO you port the code to doesn't has &quinn_utils, the verb will
    traceback with E_PROPNF, looking at the code will provide you meaningfull
    information: you don't have &quinn_utils and the code rely on it. If
    instead the code was rellying on #1788 (quinn_utils at WhatEverMOO), you
    would have to go back to WhatEverMOO to figure what the hell #1788 can
    be... If the MOO you port to has &quinn_utils, then all should works fine.

    Suggestions & comments:
    1) Make $local a kid of #0 so that all core objects are also part of the
    local core. So if in your MOO &quinn_utils is in fact $quinn_utils, then it
    will not break.
    2) Make #0 a kid of $local. The the matching of local-core objects can be
    done the same way as the matching of core object, with the $ prefix already
    supported by the server. This approach require a $local:init_for_core verb
    or a change in $wiz:make-core-database to really make a clean core. It make
    also the checking of core objects dependancy on local core objects harder.
    3) Michael Brundage suggested to evaluate &prop by using
    $local:object(prop), though I agree it can be a verb clean and exapandable
    way to make the evaluation of &prop, it might also be harder to make a two
    way conversion of the code:
    "foo || &bar:test();" -> "foo || $local:object(bar):test();" probably easy
    to translate that way... IMHO less readable than "foo ||
    $local.bar:test();" but that's a matter of taste...
    "foo || $local:object(bar):test();" -> "foo || &bar:test();" would that be
    as easy to match and translate as "foo || $local.bar:test();" -> "foo ||
    &bar:test();" At first glance I would say no, but that's only my personal
    opinion and I'm not a regexp wiz, so might not be worth much.
    4) Using to lists rather than an associate one. See comment 1.
    5) Michael Brundage also suggested $local.prop directly in the code. I
    perfectly agree that would give the same result, except that's more typing,
    in the verb code and on the command line, since the &prop ref could be used
    as args to commands. Also it would require to reqrite significantly all
    commands that support objec.property syntax and that doesn't rely on
    $code_utils:parse_propref. Also the $local.player_class.prop can be
    achieved by the & syntax above mentioned: &player_class.prop; it's a very
    good idea but imho just an extension of the local-core concept.

    Well... I hope the tour is complete. Suggestions, comments, advantages and
    ideas about the implementation are welcome.

    Janus

    P.S. I think the NewCore project is something different and a far more
    ambitious project.