Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley <[EMAIL PROTECTED]> wrote: >> Leopold Toetsch <[EMAIL PROTECTED]> writes: > >>> Dan Sugalski <[EMAIL PROTECTED]> wrote: >>> >>>> The one question I have is whether we need to have a "call class >>>> method" operation that, when you invoke it, looks up the class of the >>>> object and redispatches to it, or whether class methods are just >>>> methods called on class objects. >>> >>> The terms are misleading a bit here. >>> - a ParrotClass isa delegate PMC >>> - a ParrotObject isa ParrotClass >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> That definitely seems to be the wrong way 'round. > > Why? A ParrotClass is responsible for the method dispatch. The ParrotObject > inherits that behavior.
But logically, a Class is an Object, and an object is an *instance* of a class. Surely a class should be responsible for storing and finding method, but some other thing, call it a Dispatcher object (in Smalltalk it's the Interpreter, but we've got one of those already), is responsible for the actual dispatch. By making the dispatcher drive the dispatch sequence you can do nice things like decoupling the method cache from the class itself, just have the dispatcher maintain its own cache. Then when something changes that might invalidate the cache you just tell the dispatcher to flush its cache and carry on; no need to go finding every affected class and having them flush their caches. Having a dispatcher object helps with multimethod dispatch too of course (and where are you going to stick your multimethod lookup cache if you *don't* have a dispatcher object). Of course, if you have OO languages that have weird dispatch rules, you might need to have multiple dispatchers hanging around but (I'd argue) you're still better attaching them to classes using composition rather than inheritance.
