Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!tektronix!tekcrl!brianw
From: brianw@tekcrl.TEK.COM (Brian Wilkerson)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is SELF a naughty OOP construct?
Message-ID: <2689@tekcrl.TEK.COM>
Date: 31 May 88 16:34:14 GMT
References: <1620001@hplb29a.HPL.HP.COM> <3313@pdn.UUCP>
Reply-To: brianw@tekcrl.UUCP (Brian Wilkerson)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 72

In article <3313@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes:
>
> SELF is necessary in ST80 because methods always have one unnamed
> argument:  the receiver of the message.  Because this argument is
> unnamed, it is always called self.  This is an irregularity which
> makes abstracting over code that references SELF more difficult.
>
> To summarize:  SELF inappropriately forces algorithms to be dependant
> on which method argument is the special case otherwise known as the
> receiver of the message.

After thinking about this for some time, I am forced to disagree with you.
If the method #op: were commutative (which it was not in your example), the
names of the first and second parameters would not need to be reversed in
the process of copying the method to the expected class of the second
argument.  For example, the following method, which is commutative
(assuming, of course, that #bar: is commutative), would work equally well
in either the class of the first argument or the class of the second
argument, without changing a single character in the source code.

	op: rightArg

		^self foo bar: rightArg foo

The name of the (implicit) first parameter, self, is of no more consequence
than the name of the (explicit) second parameter, rightArg.  Your example
appears to support your argument only because the method you chose was not
commutative.  The form of abstraction that you claim is missing is the
ability to copy source code without change.  Being able to name the first
parameter explicitly would give you the ability to change the method header
rather than the body, but would still require modification of the source
code.  Non-commutative methods will always need to be rewritten.

> In article <1620001@hplb29a.HPL.HP.COM> weeks@hplb29a.HPL.HP.COM (Gregory Weeks) writes:
>
> I have a suspicion that the SELF construct may turn out to be the GOTO of
> object-oriented programming.  That is, it will be viewed as promoting
> unsound code structure.  However, I have no arguments to back up this
> suspicion.

Although Henry Lieberman [1] argues that 'self' is insufficient for
delegation-based systems, I have seen no convincing arguments that the use
of 'self' promotes unsound code structure.  The pseudo-variable 'self' can
be thought of as an implicit parameter defined for all methods.  Thus, the
use of 'self' is no less "sound" than the use of any other parameter. 

A much more likely candidate would be the use of 'super' in methods.
Sending a message to the pseudo-variable 'super' in Smalltalk-80 (for
anyone unfamiliar with this concept) causes the method look-up process to
begin in the superclass of the class in which the method containing the
send to 'super' was implemented.  For example, if there is a class B which
is a subclass of the class A, and there is a method #foo implemented in B
that sends the message #bar to 'super', the method for #bar will be found
by beginning the look-up in the class A. If there is a class C which is a
subclass of the class B, the look-up for the method associated with the
message #bar sent to 'super' in the method #foo will still begin in the
class A, even if the method for #bar has been overridden in the class C.

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'.

[1] Lieberman, Henry, "Using Prototypical Objects to Implement Shared
    Behavior in Object-Oriented Systems," OOPSLA '86 Proceedings, SIGPLAN
    Notices 21(11), November 1986, pp.  214-223.

Brian Wilkerson
Software Productivity Technologies
Tektronix, Inc.
  brianw@tekcrl.uucp