stephane ducasse wrote:
> Thanks victor.
> This is the point.
> 
> I stopped to comment these kind of "counting less classes = better" 
> argument.

The paper itself seems to have a different view on this. It states on 
p.22 "The first metric indicates that Nile has *only* one more entity 
(class/trait) than the Squeak implementation." (emphasis mine) So 
obviously the author(s) of the paper seem to feel that having "only" one 
more entity is something quite desirable. Which is why I was pointing 
out that this measure is incorrect and the correct statement should be 
"Nile has twice as many entities when compared to a corresponding Squeak 
implementation" regardless of its interpretation.

> And stop to consider all the feedback useful: we changed nile because 
> the first design
> was not good. If people like the Stream hierarchy, they can just keep it.

I like Nile. I think it contains some good ideas. But I don't think that 
much of that is due to the use of traits and I won't let people get away 
with making claims (in a journal paper no less) that have no basis in 
reality. In particular when it comes to metrics - we can disagree on 
whether the structure is more or less easily understood when using 
traits but I don't think we should disagree on how to count the number 
of classes and traits in Nile or a corresponding Squeak implementation.

> I think that we are focusing on the wrong problem and at the end
> frankly I believe that we did our job and pretty well. We will continue
> and we want to build collection hierarchy based on traits, but don't worry
> this will not be in Squeak.

Sure. Whatever. If you want to evade the discussions by running away, be 
my guest. Wrong data is wrong data though and if you keep comparing 
apples and oranges other people will ask the same questions.

Cheers,
   - Andreas