[squeak-dev] A criticism of the Nile paper (was Re: My view on
Traits)
Andreas Raab
andreas.raab at gmx.de
Fri May 16 20:38:33 UTC 2008
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
More information about the Squeak-dev
mailing list
|