[Prev][Next][Index][Thread]

# Re: wish lists

- Date: Tue, 23 Jul 1996 20:14:22 PDT
- From:
- cc: moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <5749.9607231911@dufftown.dcs.st-andrews.ac.uk>

    On Tue, 23 Jul 1996 dg@dcs.st-and.ac.uk wrote:
    > a) allowing verbs to be called with the . operator instead of : operator,
    >    i.e. object.verb(args)

    I don't think this will simplify MOO coding, and besides, everyone's
    using : now so what's wrong with it that means we should learn a new
    syntax?

    >
    > b) a mechanism for encapsulating property references.
    >
    > What I mean by (b) is probably easier to explain by example. In IdealMOO(tm),
    > there is the following piece of code:
    >
    > 	...
    > 	d.number = 5;
    > 	...
    [equates to]
    > 	d:_set_number():
    > 		object.number = arg[1];
    > 		object.description = tostr("A display panel with a ",
    > 			object.number, " on the front.");
    > 		return;
    >
    > Likewise, reading d.number would instead return the result of d:_get_number(),
    > which wouldn't be defined in this case.
    >
    > *I* think this would be extremely useful and reduce the amount and complexity
    > of code considerably, particularly integrated with (a). It would avoid the
    > extremely nasty o.description and o:description() `feature', for a start.

    It most definately will not simplify code.  When I type ;player.prop =
    "foobar", I am guaranteed that the MOO will simply set my property "prop"
    to "foobar".  Unless I do not have write access to a "prop" property on
    myself, this will not traceback.  Ofcourse, if a set_property builtin
    function were used for the raw property setting (and get_property bf for
    property getting), you could be guaranteed that way of actually setting
    the prop, unless ofcourse someone made a bf wrapper, in which case you're
    screwed if that bf wrapper traces back, and you'd then have to .program
    it to return pass(@args); and lose any code that was in it.  And, if you
    then program into the server non-overridable verbs and everyone remembers
    to define a _get_blab and _set_blab verb as nonoverridable with each
    'sensitive' property, you could keep security issues with player class
    programmers at bay... but the question is, WHY?  The () aren't even using
    up any quota, since only the compiled verb is stored in memory.  Why
    complicate things?

    Phantom  [who is in an argument with the programmer of one of the largest
    player classes on BayMOO about just why player:description should not do
    any player:tell()s, and would hate to see what would happen if wrappers
    for every property were created...]

References:

- Re: wish lists

- From: dg@dcs.st-and.ac.uk

- Prev: Re: wish lists
- Next: Re: wish lists
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index