Subject: fun with pass()

From: [email-masked]
Date: Sat, 30 Jan 1993 13:39:57 -0800

I have a question about pass()

I have a subclass of room, call it nifty_room, with lots of verbs and
properties on it.  One is a look_self property, which looks roughly like this:

this:do_cool_stuff();
pass(@args);

The default room look_self then gets called, which is:

1:  player:tell(this:title());
 2:  if (!(args && args[1]))
 3:    pass();
 4:  endif
 5:  if (player.show_exits)
 6:    this:tell_exits();
 7:  endif
 8:  this:tell_contents(setremove(this.contents, player), this.ctype);

Notice that that has a pass in it too.  Here's the problem:

I want to make a room which inherits from nifty_room, but doesn't use
nifty_room's look_self method.  So the natural thing to do is to put a
look_self method on that room.  But the issue is, I still want to use other
methods further up in the hierarchy.  Basically, I want to pass to 
two levels up, skipping the look_self on nifty_room but getting
the methods on room and the parents of room.  Is this possible?
How do I get around this problem?

-- Amy

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 19 Feb 1993 18:44:43 -0800

> Date:	Sat, 30 Jan 1993 13:39:57 -0800
> From:	[email-masked]
> 

I meant to answer this earlier, but never got around to it.

Amy, the problem here is that you've put too much into nifty_room for some of
your clients.  Don't feel badly, though; this kind of mistake is rife in MOO
programming, especially because we lack multiple inheritance (notably, the
mix-in variety).  The fix is to break nifty_room into two pieces, one
containing most of the code (I'll continue to call this one nifty_room) and
another one, child of the first, containing just the :look_self verb and its
supporting code (call this one nifty_looking_room).  Then you make your new
room a child of nifty_room, not nifty_looking_room:

			  $room
			    |
			nifty_room
			/        \
		  your_room   nifty_looking_room

Alternatively, you rewrite nifty_room:look_self to conditionalize its behavior
in some way that children can affect, such as the value of some property.

All this stuff folks were spouting about coercion seems to me a violation of
good object-oriented program design, in the areas of encapsulation,
abstraction, and information hiding.

	Pavel