Are Smalltalk Traits the same as C++ Templates/Generics

A brief introduction for those who are not familiar with C++ and its implementation of generics via templates. Templates allow you to specify the types of variables at the time when you use a type, rather than at the point where a type is declared. For example, we can implement a plus(a, b) method as such:

template <typename T> T plus(T a, T b) {
        return a + b;
}

In this example, the typename T will be substituted in when someone calls plus in one of a couple of ways. You can explicitly state which variant of plus you want to call, eg:
x = plus<int> (1, 2);

Or you can let the compiler inference it by the return type:
int x = plus(1, 2);

This essentially allows you to diverse the kind of state you're using from the behavior of the state. This is interesting because a similar mechanism was invented for Squeak several years back called Traits. In Traits, you separate behavior from a class. A trait cannot have any state, which is essentially the same as saying the trait separates behavior from state.

We can consider some direct analogies and see where they lead. For example, suppose we want to take FloatArray and make it generalized as an Array with the 'Float' part being pluggable. A small tangent -- we like to kid ourselves that Smalltalk doesn't have types, but types allow us to optimize certain kinds of use cases. Obvious examples are ByteArray, String, FloatArray, etc.

Back on track here, we would have our base class Array become a Trait and build stateful bases for collections of objects, integers, floats.. whatever you want. Then we combine the base with the trait and we can easily arrayify back to a FloatArray as a combination of FloatHeap + TArray. The direct analogy here is that in C++ we would implement std::Array<float> to do the same thing. One difference between the two languages is that with Traits, you predetermine the combinations in to a concrete class, while in C++ you determine the combinations at compile time at the point of instantiation. They of course do this by adding more syntax while Traits does not.

So this begs the question.. if the same pattern has found its way in to Smalltalk, does that mean its something very useful? One of the core benchmarks for Traits was a reshuffle of the Smalltalk-80 Stream hierarchy. You probably know my opinions on Smalltalk-80 streams because of my work on Xtreams, however it was a very interesting exercise and it allowed the developers of Traits to separate Input/Output and volatile types: File/Collection/Socket, etc from each other. Ultimately they ended up with lots of concrete classes binding all the traits back together again but that turns out to be exactly what you get in the C++ STL as well. Lots of concrete classes combining their templates in to commonly used idioms like an InputFileStream (std::ifstream is a combination of std::fstream and std::stream).

It certainly looks a lot like Traits are very useful when you come face to face with primitive types. We don't come across them very often in Smalltalk though, which would tend to lend their usefulness to the base libraries and not ever day programming. This is where may be the C++ world and Smalltalk world differ.. as the primitive types in C++ are pervasive, you find them in all of your classes everywhere and it may be very tempting to template them out so that you can make decisions about concrete types at a later date. In Smalltalk, the primitive types rapidly disappear from your problem space.

One potential anti-argument for traits/templates then is that Xtreams does not need traits to implement a significantly cleaner streaming framework that provides a great deal more utility than Smalltalk-80 streams. Another possible anti-argument is that there really are barely even a handful of situations where you stop and think "Gee, I wish I had traits right now". How often are they used in Squeak and Pharo: Very Often, Often, Sometimes, Not Often, Rarely Ever. I doubt it'd even be an issue with tool support.. the need probably doesn't arise often enough.

Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc