Subject: pass(@args) to $room && this::$room:<verb> WAY LONG

From: Andrew Wilson <[email-masked]>
Date: Sun, 31 Jan 1993 06:35:50 -0800

Greg ([email-masked]) says:

> So, to answer the question, "What could be more simple?", it is:
> 
> 	pass(@args) to $room;
> 
> I don't think there are any security problems.  I could have just
> copied the code the target ancestor would have run.  I suppose there
> might be a problem if you're using inheritance to write a 'safe
> wrapper' around an object you don't let programmers look at or inherit
> from.  I can't think of any situation where I'd do this in practice,
> though, and since the code is going to run with my permissions on my
> object (or with child permissions on child objects), I don't see why
> it matters where I get it from.

My model of 'coercion', using the obj::parent<.property/:verb> syntax, IS
explicitly designed to override any redefined semantics of a verb in favor
of the semantics of one of the verb's parent definitions.  As such, this
approach WILL definately upset any carefully constructed 'safe wrapper'
which may be present in the redefining verbs of sub-classes, ie. @kids.
A good example of such a 'safe wrapper' given by Greg is the redefined
:tell verb which some LambdaMOO player classes support to implement gagging.

In some scenarios, where 'safe wrappers' don't exist, coercion causes
no real problems.  The example I gave was of a verb which was 'neutral'
as far as coercion was concerned.  In my example, it didn't matter WHICH
:look_self verb was called, just as long as A :look_self verb was called.

My hypothetical programmer's :@describe_everyone verb:

	@program me:@describe_everyone
	for Person in (connected_players())
		player:tell(Person:title(), ":");
		Person::$player:look_self();
	endfor;
	player:tell("(finished)");
	.

treated everyone as if they were $players, regardless of what their
'actual class' really was, ie. if they were really a $slightly_modified_player
or not.  In writing this verb the programmer was aware that by coercing the
:look_self verb he/she/it could be loosing out on some of the refinement
in description offered by the redefining :look_self verbs supported by
$slightly_modified_player and $heavily_modified_player.  The programmer could
have decided in favor of coercion in this instance for several reasons:

	a) Because :look_self is a 'neutral' verb.  One which doesn't alter
	the value of any properties on the Person.  Calling this verb in
	any of its forms will not 'bother' the Person.

	b) Because the programmer wants a consistantly constructed result,
	in terms of either behaviour or actual returned value, when a verb
	is accessed.  For the programmer's purposes the behaviour of
	$player:look_self is perfectly adequate, for all objects which
	inherit their verbs and properties from $player.

	c) Because the programmer doesn't want to have to rewrite the
	:@describe_everyone verb, every time a NEW subclass of $player is
	constructed, in order to take account of any additional behaviour
	or values which that verb might return.

[Actually, a better example of a neutral verb would be :title() or
:description().  The :look_self verbs on some LambdaMOO objects WILL inform
the object that it's been scanned, and as such are 'safe wrapped'.]

It is true to say that verbs which 'safe wrap' their objects, like :tell
would be compromised by coercion.  Nasty programmers would be able to bypass
the security which MOO's current verb/property access regimen offers.  On the
face of it, the sudden arrival of coercion in LambdaMOO could cause pretty
horrendous problems for just about everyone!  So, just supposing that coercion
IS deemed useful enough to be implemented in MOO, what steps can be taken
to ensure that its arrival does not insantaniously crucify the security
mechanisms which we all rely upon?

Consider the relationship between the root class and $player:

	#1 (Root Class)
	   ^
	   |
	   | (.parent)
	   |
	$player

$player:tell implements @gagging, to prevent players from being pestered by
other players or objects that they wish to ignore.  If I (naturally being
nasty) wanted to use coercion to pester someone with annoying text then I
could simply type something like:

	;#<enemy>::#1:tell("Hey!  Dog breath!")
	=> 0

And Enemy would be justifiably upset!  This is because #1:tell implements
no form of gagging. [Or if it does in your implementation then keep quiet
about it till I've finished mouthing off ;)]  Anyways, the upshot is that
coercion will cause problems.

I've shown that there ARE situations where coercion can be of use, but that
there are just as many situations (possibly more) where it'd be a problem.
What would be nice is a means of making a verb coercable or un-coercible
to suit the situation.

Ok, lets say that we add a flag to the already-far-too-damned-many flags
which the MOO server supports.  We already have r, w, x, d, f and c, so let's
call the new flag 'n' for 'NO coercion of this verb allowed'.  Then we can say:

	@chmod $player:tell rxdn

which will mean that an attempt to coerce an access to the :tell verb of any
@kid of $player will result in an error, 'E_COERCE' say.  Now we get:

	;#<enemy>::#1:tell("Hey!  Dog breath!")
	=> E_COERCE (Coercion denied)

and suddenly everything's wonderful in MOO land again.  Mmm, but HOW does it
work?

When an attempt is made to coerce a verb, the server constructs a list which
describes the 'life' of the verb in question, in its various incarnations,
from its original definition to its possibly redefined meaning on the object
for which it was called.  Using the example of my annoying poor old Enemy, the
following list would be constructed and analysed.  This next bit is what
the server thinks when it sees what I've typed.

	Mmm, ok, so the d00d typed:

		;#<enemy>::#1:tell("Hey!  Dog breath!")

	Which means that he's trying to coerce a call to #<enemy>:tell!

	Making a list to describe the life of :tell from Enemy to the first
	place that :tell got defined I get:

		{ #<enemy>, $player, #1 }

	Ok, looking through this list I know the following things:

		a) #<enemy>:tell is just the same as $player:tell, because
		there is NO redefined :tell verb on #<enemy>.

		b) $player:tell is a 'n' verb, and I haven't even got round
		to looking at #1:tell yet so that means that I can't allow the
		coerced call to be made.

		c) If $player:tell hadn't been a 'n' verb then I could have
		Okayed it, just so long as I hadn't found any other 'n' verbs
		before I got to the end of the list.

	Sorry d00d, but hey, at least you win a E_COERCE.

If coercion was going to be foisted upon the masses then of course the
current state of existing databases would have to be taken into consideration.
Adopting an strategy similar to that used when .fertile turned up, we could
say that all verbs are, by default 'n', which means that existing security
wouldn't break.  Then the neutral verbs, like :title, :description and perhaps
:look_self could be made '!n', by, for example:

	@chmod #1:title !n
	@chmod #1:description !n
	@chmod #1:look_self !n

Of course, for added security, it should, perhaps, not be possible to do the
following:

	@create $player named "Slightly Modified Player"
	@verb "Slightly Modified Player":tell this none this
	@chmod "Slightly Modified Player":tell !n

by which I mean, once a verb is made un-coercable (n) then it stays un-coercable
in all it's redefining incarnations.  This way the owner of the original verb
can impose the semantic restriction of un-coercability [lovely, big words all
covered in honey, brown sugar and little silver frosted stars] on all the
descendants of the verb's object.  Buy, hey, HOW you do it is up to you, the WHY
is 'because its useful'.

> So, to answer the question, "What could be more simple?", it is:
> 
> 	pass(@args) to $room;

Serves me right for asking silly questions doesn't it.  Greg's solution
addresses Amy's problem perfectly.  It expands the useful vocabulary of MOO
without presenting its users with the 'horrifying' problems that 'my' brand of
coercion possibly could.  However for my own purposes, specifically for the
implemenation of a :@describe_everyone verb, I feel that Greg's solution
alone would not be sufficient.  It is very rarely, if ever, that we find
problems which MOO syntax can not address adequately.  I feel though, that
coercion, in whichever form it is needed, understood or implemented IS something
which MOO should be able to handle.

Andy - Networker

ps.

> As to Andrew's earlier example about :look_self(), I think such
> problems will not arise if programmers preserve the interface and
> conceptual behavior of parent verbs when writing overrides.

If.

You been on LambdaMOO recently? ;) A.