Two important issues...

Daniel Vainsencher 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 ;-)

Daniel

"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.
> 
> 	Andrew



More information about the Squeak-dev mailing list