Re: wish lists

• Date: Tue, 23 Jul 1996 20:14:22 PDT
• From:
  RICHARD JACOB CONNAMACHER <phantom@sfsu.edu>
• 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...]

• Re: wish lists
• From: dg@dcs.st-and.ac.uk

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