Subject: @args for inherited verb

From: [email-masked] (Billy Chambless)
Date: Mon, 6 Sep 1993 19:30:46 -0700

I've created an object which is a child of the generic container class,
but when I attempt to change the syntax of the "put" verb, using @args,
I get the message "this object does not define that verb".
How can I change the syntax? I want it to be: put any on this.

-- 
* In Real Life: Billy Chambless		    University of Southern Mississippi 
* "Blast it, Jim, I'm a programmer, not an electrician!!"
* =============================================================================

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 7 Sep 1993 16:44:26 -0700

> Date:	Mon, 6 Sep 1993 19:30:46 -0700
> From:	[email-masked] (Billy Chambless)
> 

Unfortunately, you can't shadow only the syntax of a parent's verb; you have to
shadow both the syntax and the implementation.  To do what you want to do,
you'll have to do the following:

		@verb child:"p*ut in*sert d*rop" any on this
		@program child:put
		return pass(@args);
		.

That is, you define a new `put' verb on your child object with a different
syntax and then, for the implementation, just invoke the parent's code with the
same arguments.

A flaw in this workaround is that the `put foo in child' syntax will still work
on the child, running the code on the parent directly...

	Pavel

---

From: [email-masked] (Erik Ostrom)
Date: Wed, 8 Sep 1993 04:15:44 -0700

[create a new verb "put any on this" and just have it pass(@args).]

> A flaw in this workaround is that the `put foo in child' syntax will
> still work on the child, running the code on the parent directly...

Unless you _also_ write a "put any in this" on the child, which tells
the player "You can't put anything in that!"  So then you have a put
verb on the parent; a put verb on the child with the same syntax that
doesn't work; and a put verb on the child with different syntax that
works exactly the same way as the verb on the parent.  This idea
strikes me as pretty funny, actually.

One problem with this is that $container:put in the LambdaCore
database has "in" hardcoded in one message ("What do you want to put
in foo?").  This could be altered to use prepstr, maybe I'll go do
that now.

--Erik