Re: [squeak-dev] A criticism of the Nile paper (was Re: My view on Traits)

> Hi,
>
> On Fri, May 16, 2008 at 4:38 PM, Andreas Raab <andreas.raab@...>  
> wrote:
> ...
>> 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"
>
> Less entities are not necessarily better than more, as I´m sure you
> know.  Generally, more classes with a clear responsibility are better
> than less, harder to understand, classes.
>
>> 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.
>
> But there *are* limits to what you can achieve with single
> inheritance.  It is not very hard to come up with an example:
>
> The Magnitude class is the perfect candidate for being converted into
> a trait, if you ask me.  Here is its class comment:
>
>    I'm the abstract class Magnitude that provides common protocol for
> objects that have
>    the ability to be compared along a linear dimension, such as  
> dates or times.
>    Subclasses of Magnitude include Date, ArithmeticValue, and Time,
> as well as
>    Character and LookupKey.
>
>    My subclasses should implement
>      < aMagnitude
>      = aMagnitude
>      hash
>
> Subclasses of Magnitude, by implementing #< #= #hash, gain methods #<=
> #> #>= #between:and: #hashMappedBy: #max: #min: #min:max:.  The
> subclasses of Magnitude are Number, Character, DateAndTime, etc.
>
> String does not subclass Magnitude, it subclasses ArrayedCollection,
> and yet it does implement #< #= and #hash.  It could clearly benefit
> from using Magnitude as a trait (indeed, it does implement
> #hashMappedBy: exactly as Magnitude).
>
> Having traits like Magnitude leave you more options to define a better
> inheritance hierarchy.
>
> Saludos,
>
> Víctor Rodríguez.
>
>> Cheers,
>> - Andreas
>>
>>
>>
>
>