MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

[APROG] local (long)

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.
Home | Subject Index | Thread Index