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