'isa' keyword

[Steve Holden]

phil hunt wrote:
> 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).
> 
It's the differences we are talking about. All you have said above is 
that Python and SmallTalk both use late-binding to resolve names, 
allowing them to implement polymorphic behavior.

> 
>>>>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?
> 
I'm not sure I understand this. You appear to be saying, in essence, 
"they are all programming languages, so despite the fact that they work 
slightly differently the similarity is we can write programs in them all".

> 
>> 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.
> 
Right, but it's precisely SmallTalk's message-passing techniques that 
allow this to work. Of course Python can create code blocks with 
compiler.compile(), but this is not mainstream, and Python has so many 
more-useful mechanisms to implement program control that using code 
objects as data is correctly regarded as being ion the boundaries of 
language voodoo.

> 
>>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).
> 
That we can agree on. But both differ substantially from SmallTalk.
> 
>>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?
> 
Because in Python the interpreter has hard-wired code associated with 
each operator. This code examines the left- and right-hand operands, 
calling various methods on them if they exist.

In SmallTalk the operator is the first element of a message sent to the 
left-hand operand, and if the object (or one of its superclasses) has no 
method corresponding with the operator then a "don't understand 
operator" exception is raised.

In other words, the differences aren't purely syntactic.
> 
>>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.
> 
Of course the point of Reverse Polish notation is precisely to avoid the 
need for parentheses, but we'll overlook that. I've tried to explain 
that SmallTalk expressions don;t have precedence because there is no way 
in the language to implement operator precedence, and that's because of 
the underlying message-passing paradigm of the SmallTalk virtual machine.
> 
>>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.
> 
Correct!
> 
>>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.
> 
Indeed, and that's why the use of explicit parentheses is a good 
defensive technique. But your average consumer of CP4E is going to be 
confused if the try to print 3 + 4 * 5 and get 35 instead of 23. Unless 
arithmetic teaching has changed so radically since my schooling that 
people don't understand BODMAS (Brackets, Of, Division, Multiplication, 
Addition, Subtraction) or the various other acronyms used to teach basic 
precedence.
> 
>>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?
> 
It was an early workstation built by the Three Rivers company. 
Bit-mapped graphics, many of the characteristics of the Xerox Dorado, 
but at a price researchers could afford. Its original operating system 
had many similarities with Mac OS9 (no pre-emptive scheduling!), but in 
the UK ICL produced a UNIX port called Pnix for it, and it was used by 
many projects funded by the Science Research Council.

The Burroughs disk drive was infamous because the drive belt (this 30MB 
drive was around 2 feet in diameter ...) would periodically slip off the 
motor, and you'd have to open up the cabinet to reposition it.

The Perq eventually became so despised by the computer science community 
in the UK, despite its advanced design, for the trouble it caused - the 
problem above was only one of its many unreliabilities, that after I 
left Manchester University and went to work for Sun Microsystems the 
Comp Sci department invited me back to play the John Cleese role in a 
sketch that began "I would like to complain about this Perq, what I 
purchased from this very Research Council not half an hour ago," and 
ended up with me smashing the machine with a mallet, and remarking "Now 
that's what I call a dead Perq". You can imagine the rest.

> 
>>(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. 
> 
Maybe it's you that's odd, then. Or me :-) But you've convinced me you 
know enough about SmallTalk to understand that there are indeed some 
significant differences between it and Python.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/