'isa' keyword

[Antoon Pardon]

Op 2005-09-03, Steve Holden schreef <steve at holdenweb.com>:
>> 
>> 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. 
>   In SmallTalk, control structures aren't syntactic primitives, they are 
> also examples of message-passing, so code blocks are sent as messages to 
> objects.

That doesn't seem that important to me. Should python eventually
acquire annonymious blocks, python could do the same.

> Python eschews such obscurity and (IMHO) gains clarity by so 
> doing. But that is, of course, a matter of opinion.
>
> Also, remember that just because two expressions in different languages 
> "mean the same thing "doesn't mean they are implemented using the same 
> techniques.

But it is the meaning, that defines the language, not the
implementation. So if two expression mean the same thing,
they are essentially the same thing.

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

Again you are looking at an implemantation detail, not at the meaning.

And you are wrong about python. In python you don't pass 3 and 4 to
the "+" operator. You select the __add__ method of the integer 3
which you give the argument 4. Yes I know this is a bit simplified.

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

Smalltalk could have solved that without any significant change in
implementation. Should smalltalk have decided that mathematic
expression were just syntactic sugar for messages passed to
object, a solution like in python could have been possible.
e.g. the arithmetic methods could have been called:

  @add, @sub, @mul, @div.

An expression like 3 + 4 * 5 could then first internally be translated
into 3 @add (4 @mul 5) and thus would be treated just as the expression
3 + (4 * 5) is treated now in smalltalk. This has nothing to do with
the choice in paradigma, but with the choice of how much syntactix sugar
you are willing to allow on top of your paradigma.

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

Smalltalk assumes that there is some total order in the number class
systems, and that classes that are low in this relation can be converted
to a class that is higher. So when you implement an arithmetic class,
you should decide where your class belongs and then when you implement
an operator, you should first check to see the argument is not higher
classified, if it is you should convert your object to the same class
and send the converted object the same method and argument.

It is not as flexible as python, but it mostly worked.

-- 
Antoon Pardon