Path: utzoo!attcan!uunet!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is SELF a naughty OOP construct?
Message-ID: <3325@pdn.UUCP>
Date: 1 Jun 88 16:56:13 GMT
References: <1620001@hplb29a.HPL.HP.COM> <3313@pdn.UUCP> <2689@tekcrl.TEK.COM>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 52

In article <2689@tekcrl.TEK.COM> brianw@tekcrl.UUCP (Brian Wilkerson) writes:
>In article <3313@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes:
>> 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.

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

Consider a less abstract case:

In class Collection (or a sublclass):

at: aKey insert: anObject

  ^self at: (self insertKey: aKey) put: anObject

In class Object (or a subclass):

insertAt: aKey into: aCollection    

  ^aCollection at: (aCollection insertKey: aKey) put: self

Thus one may code either "collection at: key insert: thing" or
"thing insertAt: key into: collection".

The only reason the source code for these methods cannot be identical
is because of the "self" syntax, and because the definition of the
message selector heading which defines the methods is different by
design.

Source code always has to be modified in order to create new
abstractions.  But it is bad if the code that must be modified
is the body of the abstraction, instead of or in addition to any
encapsulating code which packages the abstraction.
-- 
Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida.
Disclaimer: Do not confuse my views with the official views of Paradyne
            Corporation (regardless of how confusing those views may be).
Motto: Never put off to run-time what you can do at compile-time!