Two important issues...
danielv at netvision.net.il
Sat Feb 15 13:30:21 UTC 2003
I just understood something here (maybe). Is this cache variable the
only reason we need to recompile everything? Just externalize it, like
Object>DependentFields. This removes the ClassBuilder dependency, and
makes Traits much more compatible with the current state of Squeak. Then
it can become a package, which would be more accessible.
Besides that, publishing the MI cache in advance sounds like a good
idea. Could you elaborate more on what information is cached, what hooks
are used, and space requirements? (not that I think the last is very
inflexible, but if it's 200M, it might be a problem ;-)
"Andrew P. Black" <black at cse.ogi.edu> wrote:
> Previous to this thread starting, I had raised another possibility
> with Nathanael for the future of traits.
> Traits themselves are pretty easy to make available as a changeset,
> for people to try out in their own image. They don't require any VM
> changes or even any changes to the compiler (although a small change
> to support super directly would make traits more space-efficient).
> However, it is the traits browser that makes traits a usable and
> attractive programming tool. The browser relies on getting fast
> information about the self-sends and super-sends of every method in
> the class that is being browsed. It isn't practical to re-parse the
> source of each method to get this. So one of Nathanael's major
> enhancements was to add a cache for this information, in a compact
> form, and to recompile the world once so that it quickly available
> for all methods.
> My suggestion was to add this Method Information cache to core Squeak
> as soon as we can. The rest of the traits package could then be made
> available to members of the community to play with in their regular
> programming image, rather than in our "special" traits image. The
> method information cache also enables some other useful tools for
> introspecting on code. For example, I had some code that extracted
> the interface from a class; this means excluding not only all of the
> "self shouldNotImplement" methods, but also all of the methods that
> call those methods, and so on recursively. The method information
> objects gave me the tools to do this efficiently.
> Putting the method information calls into the core doesn't directly
> change anything: the current implementation of traits still a bit
> buggy, and Nathanael is not keen on releasing anything that is not
> perfect. Frankly, I think that the traits browser is already just as
> usable as most of the other tools in Squeak, and the best way of
> making it more robust is to release it and have others improve it.
> The effect of the method information cache, however, is that the
> results of buggy code can be cached and come back to haunt you weeks
> after the bug has been fixed ... not always nice.
> Anyway, I though that it was worth discussing this compromise: if
> many people would like to see it, and, more importantly, are willing
> to work on the stability issues, then it could happen regardless of
> what the folks in Bern do.
More information about the Squeak-dev