About Tim fix on allCall for interpreter plugin

Tim Rowledge tim at sumeru.stanford.edu
Sun Aug 24 22:43:56 UTC 2003


In message <27D15FB0-D608-11D7-B25F-000393B2AA24 at iam.unibe.ch>
          Stephane Ducasse <ducasse at iam.unibe.ch> wrote:

> 
> On Saturday, August 23, 2003, at 07:27 PM, Tim Rowledge wrote:
[snip]
> > Which names are you referring to? Probably #allCallsOn I guess; so I 
> > can
> > only say that since it becomes a unary message it seemed like the
> > obvious answer. If you can think of better names do feel free to use
> > them.
> 
> 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? 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