Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41539 > unrolled thread

Re: [Python-ideas] Message passing syntax for objects

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Python-ideas] Message passing syntax for objects Terry Reedy <tjreedy@udel.edu> - 2013-03-19 16:09 -0400

#41539 — Re: [Python-ideas] Message passing syntax for objects

On 3/18/2013 11:31 PM, Andrew Barnert wrote:

> The idea that message passing is fundamentally different from method
> calling also turned out to be one of those strange ideas, since it
> only took a couple years to prove that they are theoretically
> completely isomorphic—and,

Since the isomorphism is so obvious, I somehow missed that Kay actually 
thought that they were different. I suppose one could have different 
(but isomorphic) mental image models.

For me, the problem with message passing, as usually though of, or 
method calls in their usual syntax, is the breaking of symmetries such 
as the commutivity of number addition. I think of 'a + b' as a message 
to the interpreter, as supervisor of Python objects, to add a and b 
together and give me the result. It turns out that a Python interpreter 
does that by calling *either* a.__add__(b) or b.__add__(a) or possibly both.

The advantage of passing messages through a supervisor is that it can 
'supervise' the process. The behavior with binary operators is one 
example. The behavior of len(c) is another. If c.__len__ does not exist, 
(the programmers fault for calling len(c)), it raises one message. If 
c.__len__ does not return a non-negative int, it raises another.

 > for that matter, they're both isomorphic to closures.

Translating into Python, does this refer to the fact that bound methods 
are closures?

> In effect, your "objects" are just single-parameter functions, and
> your "messages" are the call operator.

The proposal seems to be that every object should have a 
single-parameter call method that in turn calls a preferred, default 
single-parameter named method.

For lists: def __call__(self, ob): self.append(ob)
For ints: def __call__(self, other): return self.__add__(other)

That seems useless as a general pattern.

-- 
Terry Jan Reedy

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web