> > 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. _______________________________________________ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor