Two important issues...

Andrew P. Black black at
Sat Feb 15 06:51:50 UTC 2003

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 mailing list