Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!alice!shopiro From: shopiro@alice.UUCP Newsgroups: comp.lang.smalltalk Subject: Re: Is SELF a naughty OOP construct? Summary: SELF is fundamental to object oriented programming Message-ID: <7935@alice.UUCP> Date: 31 May 88 15:51:21 GMT References: <1620001@hplb29a.HPL.HP.COM> <3313@pdn.UUCP> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 55 Posted: Tue May 31 11:51:21 1988 > In article <1620001@hplb29a.HPL.HP.COM> weeks@hplb29a.HPL.HP.COM (Gregory Weeks) writes: > >No. In article <3313@pdn.UUCP>, alan@pdn.UUCP 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. > The issue is even more fundamental than you have said. The method belongs to a class, and the language guarantees that the receiver is an instance of that class or one of its subclasses. The language does not guarantee anything about the arguments (except that they exist). Thus, for example, the method can access the instance variables of only the receiver. When you write in ST-80 leftArg op: rightArg it means ``send the message op: with the argument rightArg to leftArg.'' Then the class of leftArg (only) determines what happens next. Sometimes you would like this expression to mean ``apply the operator op: to leftArg and rightArg,'' Where op: looks at both leftArg and rightArg to determine what to do. These concepts are different and simulating either one with the other can be a real pain. The most obvious example where the second meaning is desired is arithmetic. Making SELF into an explicit argument would not appreciably simplify this problem, which is intrinsic to object-oriented programming. > > 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. > My summary: Object-oriented programming focuses on objects, which makes applications that need to focus on operations difficult. Caveat: Focussing on objects is exactly the right approach for most (but not all) applications. > -- > Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. > Motto: Never put off to run-time what you can do at compile-time! Right on! -- Jonathan Shopiro AT&T Bell Laboratories, Murray Hill, NJ 07974 research!shopiro (201) 582-4179