Re: More Questions
bluke: In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking.
Can you give some concrete examples of the different ways of thinking? You mention distributed systems in your message. Any others?
The ability to capture messages can be very useful. For example, undo/redo can be implemented using this (you trap every message sent and then you can either undo them or redo them quite easily as you have the original message). Logging security can be done with this facility as well.
The other place its shows is in areas like constructing new objects, conditional logic, etc.. In Java, you have a special keyword new and a constructor is called. In Smalltalk, all you do is send a message to the class object to create a new instance, perfectly logical. In Java if then else is a language construct. In Smalltalk it is a message send. When you think in terms of messages, it makes sense to send a message for everything including object creation and conditionals.
bluke: A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases.
Is this a hard requirement? Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help?
I am not an expert on type inference or Haskell, but I don't see how it would help. For example how would it handle a proxy object which can take any message and just forwards it somewehere? A static type system would just impose constraints. Of course, using DoesNotUnderstand is not the normal way of doing things in Smalltalk, so type inference might be useful in those other cases.
