phil hunt wrote:
> On Thu, 01 Sep 2005 20:39:14 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>phil hunt wrote:
>>
>>>It could be argued of course, that an OOPL should allow methods to
>>>be sent with a grammar:
>>>
>>> receiver selector argument
>>>
>>>(which is almost what Smalltalk does), but you're not arguing for
>>>that (and I'm not sure it would work with the rest of python's
>>>grammar).
>>>
>>
>>Even if it did it might mangle operator precedence in the same way
>>SmallTalk did, which I always felt was one of the least attractive
>>features" of the language.
>
>
> That's certainly a point of view; another is that Smalltalk
> simplified things by making all operators the saem priority. For
> those that don't know smalltalk, in that language:
>
> a + b * c
>
> means:
>
> (a + b) * c
>
>
>>I don't think a change to a message-passing paradigm
>
>
> 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.
> so it is purely a matter of aesthetics which is preferred. Havcing
> said that, I don't see a big benefit in changing Python's syntax in
> this way.
>
Me neither. And I can see positive disbenefits, like it would confuse
the hell out of most people :-)
>
>>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.
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.
Also, remember that just because two expressions in different languages
"mean the same thing "doesn't mean they are implemented using the same
techniques.
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).
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. 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.
Also, try seeing what the mathematicians have to say about a language where
a + b * c
means
(a + b) * c
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. It
seems to me that Guido's primary achievement with Python's design is to
provide a language that allows the expression of object-oriented
paradigms in a way that seems natural even to people who are new to
object-oriented concepts.
I'm glad you haven't done much object-oriented stuff in PHP, because its
object-oriented paradigm is about as sensible as Perl's (which is to say
it was a bolt-on extension that resulted in an extremely unnatural mode
of expression). The fact that people can write object-oriented code in
these languages is a testament to the flexibility of human thought
rather than a benefit of the languages' design.
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. (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.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list
