[Tutor] class overriding question

[Alan Gauld]

> > Its another reason why you should never refer to
> > an object or method *calling* another method
> > (as Pilgrim does). Rather think of the method
> > sending a *message* to the self object which
> > invokes the appropriate method.

> The contrast you suggest between calling a method and sending a
message
> to an object isn't immediately clear to me. I'll put on my puzzling
cap.

In classical OOP theory - ie all the early OOP languages
(except probably Simula which was Algol based!) - the metaphor was of
a set of independant objects floating around in cyberspace. These
objects communicated by sending messages to each other. How the
receiving object responded to a message was known as its method,
and the resolution of the message into appropriate method was the
job of the receiving object (or class).

In (pseudo and simplified python-like) Lisp, for example,
you can do things like:

def methodOne(self, p1):  # code here
def methodTwo(self, fmt):  # code here

def class MyClass

myClass.addMessage("help", methodOne)
myClass.addMessage("print",methodTwo)
myClass.addMessage("display", methodTwo)

myObject = MyClass.makeInstance()

myObject.send("print", 'txt')
myObject.send("display", 'scrn')

Thus I bind the same method to two different messages.
Because I always use send() (a class function) I pass
the message name as strings and the class  does a lookup
(usually in a dictionary) and calls the associated method.
THus there is explicit separation of concept.

Unfortunately this was slow so most later OOP languages
opted for a more direct translation with message name
equalling method name. This in turn lost the theoretical
purity of the concept of objects being independant concurrent
processes and starte the idea that you could directly
call a *method* which theoretically is impossible.

But conceptually it helps to see the difference between
objects and data structures to imagine that every object
is an independant process and they communicate by sending
IPC messages to one another. ( For the mathematically
inclined this idea of concurrent sequential (state)
machines is a very powerful formal model that can be
analysed mathematically. Many of the theoretical
underpinnings of computer science stem from this idea.)

> But do you suggest it to emphasize that it is features of the object
> that determine which method gets invoked by the object.method()

In essence yes. The programmer has no control over the
code that gets executed when he "sends a message" to
an object, that is determined in the class. And it can
be a dangerous mistake to think otherwise - after all
what if someone subclasses your original class and then
passes one of the new objects into your code. If you
assume that you can send a message and execute a
specific method you might be in for a nasty surprise!

As a specific example, lets say you have a set of blodgets.
One method of the blodget superclass defines a save method
which writes to a fixed data file. You write code that accepts
a blodget (or any subclass thereof) and saves it then reads
the data file to access some aspect of the object - really
bad practice anyway but it happens! Now I come along and
define a subclass of blodget that saves by writing to a
serial comms port, now your code "saves" my blodget but
when it reads the data file it actually picks up the last
blodget details not mine - oops!

I hope that short history of OOP clarifies rather than
confuses! :-)

Alan G.