'isa' keyword

[phil hunt]

On Sat, 03 Sep 2005 00:45:19 -0500, Steve Holden <steve at holdenweb.com> wrote:
>> I'm not talking about a change in *paradigm* merely a change in 
>> *syntax*; this:
>> 
>>    receiver selector argument
>> 
>> would mean the same as the current Python:
>> 
>>    receiver.selector(argument)
>> 
>Aah, I see. I had assumed that "selector" was always going to be an 
>operator. 3 . (+ 4) does indeed seem very "SmallTalkative". I don't 
>think that Python method (or attribute) selection bears any relationship 
>to SmallTalk message-passing, but I hope you will feel free to enlighten me.

Let's consider the Python example first.

You have two classes A and B. Each has a method called 'selector'.

When the line of code above is executed, the Python virtual machine 
decides whether (receiver) is a member of A or B, and then executed 
one of A.selector() or B.selector() depending on which it is. 
Whichever function is executed, it is passed with (reciever) as the 
"self" argument so that the correct data is operated on.

And now let's consider the Smalltalk example. How does it do it? 
Essentially it does *exactly the same thing*.

(Yes, I know there are many differneces in detail between how 
Snalltalk and Python  work, but they are only *details*; the 
fundamental idea governing how these two object-oriented languages 
work is the same).

>>>would necessarily 
>>>benefit Python at this stage. Some people are still under the 
>>>misapprehension that message-passing is a fundamental of object-oriented 
>>>programming because of Smalltalk, but they are wrong.
>> 
>> 
>> I don't see how it can reasonably said that STK has 
>> "message-passing" but other OOPLs don't. Consider these code 
>> fragments:
>> 
>> Smalltalk:
>>    receiver selector: argument
>> 
>> C++ or Java:
>>    receiver.selector(argument);
>> 
>> Python:
>>    receiver.selector(argument)
>> 
>> PHP:
>>    $receiver->selector($argument)
>> 
>> (I'm not sure if the last one is right since I've not done much OO 
>> stuff in PHP)
>> 
>> These all mean essentially the same thing so how can one be "message 
>> passing" and the others not?
> 
>Sorry, they don't all mean "essentially the same thing" at all. It seems 
>to me you are looking at SmallTalk in entirely too superficial a light. 

OK, allow me to reprase it. Imagine a language ith the semantics of 
Python but the syntax of C++ or PHP or Smalltalk (or Lisp for that 
matter). It would still basically be Python, wouldn't it?

>  In SmallTalk, control structures aren't syntactic primitives, they are 
>also examples of message-passing, so code blocks are sent as messages to 
>objects. Python eschews such obscurity and (IMHO) gains clarity by so 
>doing. But that is, of course, a matter of opinion.

I agree, that's a major point of departure between Python and 
Smalltalk.

>Also, remember that just because two expressions in different languages 
>"mean the same thing "doesn't mean they are implemented using the same 
>techniques.

Of course not. 

CPython and JPython are different implementations, but they are 
still the same language (mostly).

>I would contend (if backed into a corner) that there is a significant 
>difference between passing the arguments 3 and 4 to a "+" operator 
>(which is what Python and most other languages implementing standard 
>ideas of operator precedence do) and sending the message "+ 4" to the 
>integer 3 (which is effectively what SmallTalk does).

In both python and smalltalk you can override the operator to mean 
what you want, so I disagree that there is any fundamental 
difference. Why do you think there is?

>Of course, I realise that you can argue that the two are equivalent in 
>the sense that they perform the same computation. But SmallTalk's choice 
>led to the loss of operator precedence, which is something that is 
>pretty fundamental to mathematics. 

Surely that's a separate issue, one purely of syntax. Imagine two 
languages:

   (* (+ a b) c)

and:

   (a + b) * c

These both mean the same thing, they just say it differently.

>Also Python allows much more 
>flexibility by hard-wiring operators and allowing alternatives to be 
>considered (if the left operand doesn't have an "__add__" method then 
>try to use the right operand's "__radd__" method). SmallTalk doesn't 
>have any parallel to this that I can think of.

You're right; in Smalltalk you'd have to code that functionality in
the method for the left-hand object.

>Of course it isn't only mathematicians who are taught to us the 
>precedence rules, so I contend that SmallTalk would seem 
>counter-intuitive in a "Programming for Everyone" context as well. 

Probably. 

However consider that a language (e.g. C++) may have lots of 
operators, e.g: & && | || << >> <= >= < > ^ % etc. Is there an 
obvious natural order of precedence for all these? I suspect that 
many C++ programmers couldn't put all its operators in the correect 
order.

>I speak as one who was partly, and in a minor way, responsible for 
>implementing the SmallTalk system on the Perq architecture back in the 
>1980's. 

What's Perq?

>(Mario Wolczko did the real work). So it's not that I've just 
>looked at SmallTalk and find it odd. It's just that it treats 
>expressions in a way which ultimately appear to seem counter-intuitive 
>in contexts like arithmetic expressions.

I personally didn't find it odd, it felt quite natural to me. 

-- 
Email: zen19725 at zen dot co dot uk