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
--
http://mail.python.org/mailman/listinfo/python-list
