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