Path: utzoo!attcan!uunet!husc6!psuvax1!rutgers!rochester!cornell!uw-beaver!tektronix!reed!bart
From: bart@reed.UUCP (Bart Massey)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is SELF a naughty OOP construct?
Message-ID: <9438@reed.UUCP>
Date: 1 Jun 88 08:49:21 GMT
References: <1620001@hplb29a.HPL.HP.COM> <3313@pdn.UUCP> <2689@tekcrl.TEK.COM>
Reply-To: bart@reed.UUCP (Bart Massey)
Organization: Reed College, Portland OR
Lines: 32

In article <2689@tekcrl.TEK.COM> brianw@tekcrl.UUCP (Brian Wilkerson) writes:
> I would argue that any code sending a message to 'super' (other than the
> one being overridden) should be highly suspect.  Chances seem very good
> that it will reduce the amount of code that can be inherited by subclasses
> by forcing them to override the method containing the send to 'super' in
> order to affect an override of the message being sent to 'super'.

Agreed.  But the special case you mention -- invoking the "old" behavior of
a method to do most of the work -- covers most of the usages of super that
I've seen in actual code.

Perhaps what is wanted is something more restricted.  Something like Object
Pascal's "inherited" operator.  Imagine that e.g.

	newOn: bletch
		^ (overridden newOn: bletch) setSubclassInstVar: nil
		
is legal, but

	newOn: bletch
		^ (overridden new on: bletch) setSubclassInstVar: nil

is not.

I guess the semantics of the "overridden" pseudo-object are that it responds
to at most one message -- the selector and method for this message being the
selector and method overridden by the current method definition.  Given this
psuedo-object, I think I'd happily sacrifice the "super" pseudo-object.  Am
I wrong?  Am I missing something important?  Am I totally confused?  Only
my hairdresser knows for sure...

							Bart