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