About Tim fix on allCall for interpreter plugin

Andreas Raab andreas.raab at gmx.de
Sun Aug 24 23:01:52 UTC 2003


> > No I mean the fact that a method does not refer to the 
> > class but the module name.
> Ah-hah! I really don't recall why that was done originally. Maybe
> Andreas does?

Geesh, guys think about this for just one second: This is a primitive
_invokation_ and the invokation doesn't know anything at all about whether
the underlying primitive was generated from Slang classes or not. There
simply is no relation whatsoever between the primitive invokation
(<primitive: foo module: Bar>) and the primitive implementation which is
exemplified by the fact that you a) have to compile a new VM for it to take
effect and b) you can throw out all of the plugin classes with no effect on
the running system whatsoever.

In short, having a reference to the slang plugin class simply has no meaning
in the context of primitive invokations. The slang plugin class isn't even
involved in what's happening at runtime.

Cheers,
  - Andreas

> Currently the name of a plugin is set at 
> generate time by
> its response to #moduleName. In many cases this is the default of the
> class' name. At one time I was strongly in favour of making the plugin
> name match the class name and renaming some of the plugin 
> classes to be
> a bit more logical. Of course this involves changing a lot of 
> methods as
> well and potentially causing a lot of compatability problems. THe
> general idea was tabled until the fabled image format change junta.
> 
> However, having thought about it more I think that there is a good
> reason to at least allow the plugin name to differ from the 
> class name.
> For example, if I want to make an Acorn specific FilePlugin I could do
> so by making a subclass of FilePlugin and overriding the#moduleName
> method. Thus my new plugin would be found by all the normal references
> to FilePlugin and all would be well.
> 
> Another complication is that the methods referring to plugin 
> methods do
> not have the global association for the plugin name but just 
> the actual
> string. Thus we need to have the extra code in InterpreterPlugin to
> account for that.
> 
> I suppose one possibility for 'reverse lookup' would be to make a
> dictionary (in InterpreterPlugin?) of all the responses to #moduleName
> and the matching classes. Given the possible overrides 
> mentionedabove we
> would have to make sure that the entire mechanism could cope with
> multiple answers.
> 
> [snip]
> > 
> > To write a test I guess that we have to load VMmaker. Right?
> To do a full test of the code working with plugins and still 
> working ok
> with ordinary classes, yes I think so. It wouldn't be terrible to make
> a fake class tree to pretend to be InterpreterPlugin but 
> perhaps a waste
> of time.
> 
> 
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- A natural talent for finding 
> subliminal messages in ice cubes.
> 



More information about the Squeak-dev mailing list