"Andreas Raab" <andreas.raab at gmx.de> wrote:

> > Not quite as simple as it might seem; since you cannot 
> > guarantee that a method will be found in any particular
> > class you would need some tag mechanism to say that you'd
> > already done all required fetching.
> 
> Actually you don't. Dan built in this mechanism that the VM signals a
> #cannotInterpret: exception if the method dictionary of a class is missing
> (nil). AFAIK, this should work perfectly well as long as you don't want to
> do this on individual method level.
Exactly; I was refering to a method by method upload. Grabbing an entire
class is premature optimisation; why, it might be being written/extended
as you try to fetch it! No, it's quite obvious that you need to only
fetch each method as needed and in fact there should be a mechanism to
flush the cache anytime the central repository version is updated. In
fact, I think one should go further and only fetch each bytecode of
the method as it is needed. Why load bytecodes that are always skipped?
This is of course a Just in time Bytecode system, or Jibber(tm). Hmm,
somebody write a paper on the subject and submit it to some java
conference as the new big thing. They're dumb enough to bite.

> 
> Hm ... thinking about this - you could do it on a per-method level if you
> just tell the other side which selectors are implemented. In this case the
> MD could be stubbed out with methods which pull in the appropriate
> implementation and continue from there.
It's that premature binding again; why would you know in advance what
methods are implemented in any class? OK, I'll conceed a possibility of
doing that so long as there is a flushing mechanism for when a new
method is added on the 'server'. Waiting on a socket would probably do
it.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- If what you don't know can't hurt you, she's
practically invulnerable.