[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Messages as objects
This may be too radical for some of you guys, but I would like to suggest
that messages should be objects [and not just symbols]!
So far, none of the Lisp-embedded object systems permit this, although fully
object-oriented systems like Smalltalk and Actors do. But it is worth thinking
about making sure this can eventually be done. Here are some reasons
why [I've got more if anyone wants to discuss it]:
- Implementing "local messages", as Kent suggests, is possible this way,
without relying on packages, keywords, etc.
- Inheritance can be used for messages, just like objects. The user might
want a message that's "just like the print message, except ..." which clearly
calls for inheritance. This makes a nice duality between messages and
objects which receive messages.
- Sometimes, the user would like to implement one handler to handle a
group of related message "keywords", without having to define a separate method
for each keyword. Example: An object might want to say, "Send all messages
having to do with graphics to the graphics-manager object" where these might
include :DRAW, :ERASE, etc. One would also like to avoid burning in a specific
list of these, possibly having a procedural test as to whether a message was
a graphics message or not.
- Implementing "default behavior" for messages. Often, the behavior of
object systems is extended by introducing new messages to which every object
should have a response. Examples are :PRINT [everything should print],
:EQUAL [everything should say whether it is equal to something else].
Traditionally, these are done by defining methods on the root of the
inheritance hierarchy [OBJECT in Smalltalk/Loops, VANILLA-FLAVOR in Flavors].
The problem is that as these proliferate, the root becomes a bottleneck,
accumulating large numbers of methods. The obvious solution if messages
are themselves objects is to give each message object a :DEFAULT method
which can be used to respond if the object does not have an idiosyncratic
response. If an object does not have a :PRINT method, OBJECT turns around and
sends the :PRINT message a :DEFAULT message to print the object.
This is probably the most important practical reason to allow messages
to be objects.