Damien Cassou wrote:
> For a discussion about these questions and the Stream hierarchy, have
> a look at «Traits at Work: the design of a new trait-based stream
> library» http://www.iam.unibe.ch/~scg/Archive/Papers/Cass08a-NileNewKernel-ComputerLanguages.pdf.
> Here, we identify all problems with the current Stream hierarchy,
> design a new one based on traits and discuss the differences and
> drawbacks.

This is a very nice paper but it falls into the same trap that other 
traits papers fall into - it confuses ideas that are just as applicable 
to single inheritance with traits and claims that (just because traits 
have been used to implement the original idea) traits are superior.

For example: In section 7.3 some metrics are given that compare the 
Squeak implementation with Nile's implementation of internal streams. 
Based on the (superior) version in Nile it says that "This means we 
avoided reimplementation of a lot of methods by putting them in the 
right traits. Finally, we can deduce from the last metrics that the 
design of Nile is better: there is neither cancelled methods nor methods 
implemented too high and there are only three methods reimplemented for 
speed reasons compared to the fourteen of the Squeak version." with the 
strong implication that it was traits that helped to achieve the 
majority of the improvements.

But is that so? Let's look at section 4.1 and note that here it is 
pointed out that "The library implements all collection-oriented methods 
in a single class: CollectionStream. This class replaces the three 
classes ReadStream, ReadWriteStream and WriteStream of the traditional 
Smalltalk stream hierarchy (See Figure 1)." This approach is definitely 
an improvement but every bit as applicable to a single inheritance 
implementation of streams.

It is interesting to do a quick check to see how much this might change 
matters: First, combining these three classes into one means that the 
traits version has now twice the number of entities vs. the non-traits 
version (3 vs 6). This view is also supported by counting the "backward 
compatible" part of Figure 12 (which is directly comparable with the 
Squeak version) which results in 11 classes and traits (compared to 5 
classes in Squeak).

Next, if we take the total number of methods in these three classes:

   ReadStream selectors size +
   WriteStream selectors size +
   ReadWriteStream selectors size
   -----------------
   68

(the measure was taken in 3.9 to be roughly comparable with the paper 
and I'm not sure why the paper claims 55 methods) and compare this with 
the number of unique selectors (discounting all re-implemented methods):

   (Set withAll:
     (ReadStream selectors asArray),
     (WriteStream selectors asArray),
     (ReadWriteStream selectors asArray)) size
   -------------------
   59

What we get is 15% improvement *minimum* by folding these three classes 
(very likely more if one looks in detail).

Next, let's look at "canceled methods" (those that use 
#shouldNotImplement). The paper lists 2 canceled methods which happen to 
be WriteStream>>next and ReadStream>>nextPut:. And of course those 
wouldn't exist in a single-inheritance implementation either. Etc.

In other words, the measures change *dramatically* as soon as we apply 
the original idea regardless of whether traits are used or not. Which 
speaks clearly for the original idea of folding these three classes into 
one but concluding that traits have anything to do with it would require 
a very different comparison.

If the paper wants to make any claims regarding traits, it really needs 
to distinguish improvements that are due to traits from general 
improvements (i.e., improvements that are just as applicable to 
single-inheritance implementations). Otherwise it is comparing apples to 
oranges and can't be taken seriously in this regard.

Cheers,
   - Andreas