Last week, I said that instance variables are public in Smalltalk. That is not the case. I got confused because we are working on an improved version of Smalltalk and because of representation independent code, instance variables are public until we add a general mechanism for declaring non-public methods.
My point that Squeak (and Smalltalk) are not good examples for API design remains valid, however.
I’m doing a lot of Smalltalk programming these days, and it’s great fun. The language is very powerful and flexible. However, my experience is with a bastard child of Smalltalk: Squeak. This is a complete mess because it seems like every library adds a few methods to core classes like Object and Class. For example, Squeak has a XML (sigh) library named SIXX, and its brilliant developers felt they had to add 18 (eighteen!) methods to Class. Here is the brilliant part: everything is public in Smalltalk, which means that you do not have to add a method to an object to access its instance variables.
Contrary to popular belief, everything is not a lock (in Java java.lang.Object is a lock, making almost everything a lock); keeping the number of methods to a bare minimum in core classes keeps everything simpler and easier to learn. Here is how I believe the core classes should look like:
So what about all the utility methods you normally find in these classes in both Smalltalk and Java?
They belong in utility classes. For example, everything related to regular expressions should live in a separate library. But what about reflection?
you ask. You will find the answer in Gilad’s fine paper on mirrors. I believe many of the considerations of the mirror paper apply to software engineering in general.