I've blogged before about some ill-defined notion where the differentiation between classes and namespaces was made less instead of more. Basically, I wanted to be able to define a class as a private class of another class. Classes are namespaces for shares, allowing them to be any type of object BUT declare classes. And having done a couple of the tools, I can attest to the fact that this just makes things harder than they should be.

This evening, I found myself wanting the opposite. I wanted to create a namespace for simple shares and place that namespace inside of a class. I'm not sure what that does to my "namespaces should just be classes" notion. But it's an interesting twist to my struggles with these things.

The intended use was/is for library constants. When you're doing a library interface like that for Cairo, there are a plethora of constants to define different things. In C they would be grouped by typedef'ing an enum. But enum's are not a natural element of Smalltalk. DLLCC provides a model of an enum, but if you have to access lots of these named constants, that's pretty tedious. Furthermore, the cairo interface is pretty good about grouping these constants with a given "object" type.

For example, stroke (or line) cap styles. In C, you'll have long tedius names like CAIRO_LINE_CAP_BUTT, CAIRO_LINE_CAP_ROUND, and CAIRO_LINE_CAP_SQUARE. And there's family after family of these. The code I'd like to be able to write is:

aCairoContext strokeCap: CapStyles.Square