Smalltalk: Extending the Kernel
Motivation
Many time I wish I could send a non-existent message to an object that’s part of the built-in Smalltalk library.
For example:
String>>surroundedByDoubleQuotes ^ $" asString, self, $" asString. |
Packaging
Simple Case: Project-specific Extensions
In Pharo, I can store this method in a package different from the one of the class in question. This is called an “extension method” and the implementation is currently a bit of a hack… You put the method in a protocol that starts with an asterisk followed by the package name. Thus, for the example above, if my project was packaged in MyPackage, I could package the method with it like this…
For methods that are project-specific, this is all we need (although hopefully now that Pharo is working on first-class packages, it would be great if we could have both a protocol and specify an extension). However, the method above really has nothing to do with a particular project. It seems generally useful; and indeed, I find myself using it over and over.
Generally Useful Extensions
In these cases, it doesn’t work to package the method with the project that uses it, because if more than one of these projects are loaded into the same image, one method will override the other, creating a mess in Monticello. So I’ve been experimenting with two approaches.
The naive way would be to package all such methods in one package, e.g. “PharoExtensions”. This is the first thing I tried, but I was a bit uncomfortable with the all-or-nothing idea – that I’d have to load every extension I’ve ever created to use just one.
The most flexible tack is to package each method individually. The method above could be in the “StringSurroundedByDoubleQuotes” package. This way, one could load the method without effecting any other parts of the system. However, a package is a bit heavy-weight for just one method.
A Compromise
The current idea I’ve been playing with is to mirror the existing package structure of Pharo. For the above, String lives in “Collections-Strings”, so I tack on a standard suffix, making it “Collections-StringsSpd”. Now, we can load extensions for only the packages we are using, without having a confusing mess of ClassNameMethodName packages.
