[squeak-dev] My view on Traits

> Klaus D. Witzel wrote:
>> I think you can easily judge for yourself whether or not a system gives  
>> you multiple inheritance (MI):
>>  o in Smalltalk every class has at most one superclass
>> o every MI class has at least two superclasses
>> o in Smalltalk a method can send to self or super
>> o a method in an MI class can choose to which super it sends
>>  Compare Squeak's traits to these statements ...
>
> I don't think this is a particularly good definition of MI but the above  
> certainly applies to traits: When a class uses a trait it certainly has  
> multiple superclasses for all its observable behavior;

> Hi,
>
> On Fri, May 16, 2008 at 4:38 PM, Andreas Raab <[hidden email]>  
> 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
>>
>>
>>
>
>

> For table 6, which methods did you consider to be implemented too
> high and are these counted in the total number of methods (which I doubt
> since the total number of methods is too small to include methods in
> superclasses so by definition it shouldn't count those).
>
> About FileStream, History and Decoder: Please provide a definition of
> "cleanly implement" so that I can see if a solution to the problem exists.
> FileStream and Decoder look fairly straightforward though so unless you have
> a very restricted definition of "clean" I'm pretty sure I can come up with
> something.

> Damien Cassou wrote:
>>
>> Please have a look at the NSMetrics class. Here, you have the methods
>> which generate the tables and their numbers. If you find any problem
>> with the algorithms, please tell me.
>
> Excellent, thanks. I had never seen NSMetrics before. Is there a particular
> version of Nile that should be used for those measures? I tried 0.9.5 (the
> latest published universe version available in 3.10) and it blows up, first
> because there is no trait NSTCollectionStream and later because it sends
> #overridesSelectors which isn't implemented anywhere.

>
> On 17-May-08, at 1:36 PM, Avi Bryant wrote:
>
> On Sat, May 17, 2008 at 9:48 AM, Colin Putney <[hidden email]> wrote:
>>
>> Heh - I've long had nearly the opposite question: Why was support for
>> read-write streams ever needed? I can't recall *ever* using it in my own
>> code, nor encountering it in anyone else's.
>
> What about files?
>
> Good point. A lot of files are read-only or write-only, but not always.
> MC2's file repository both reads and writes on the same file stream. So I
> guess I have encountered it in someone else's code. :-)
> Still, I do think separate streams for reading and writing to the same file
> would be fine as an API.
> Colin
>

> Damien Cassou wrote:
>>
>> I'm sorry. I haven't updated the universe package for some time.
>> Please use SqueakSource and load Nile-All. This package depends on
>> other required package and contains NSMetrics.
>
> Okay, after loading this I understand better where the numbers come from.
> First, a couple of comments on NSMetrics:
> #methodsInClassAndMetaclass:methodListBlock: does a union of methods in
> class and metaclass which looks a little questionable to me. I don't think
> it matters here but it seems odd to count a method in class and metaclass
> only once. The #numberOfReimplementedMethodsForClasses: also has two
> problems in such that it does only look at methods overridden in the direct
> superclass (so it doesn't find methods implemented in Stream and overridden
> in ReadStream but not in PositionableStream) and that it excludes the
> required selectors of traits but not those of superclasses (i.e., self
> subclassResponsibility) which it should discount as well (see note below on
> the metrics that are affected by it).
>
> That said, we can now devise a comparison which is more appropriate for a
> Nile vs. Squeak comparison. I've attached a simple class InternalStream
> which as a subclass of PositionableStream implements the same folding of
> ReadStream, WriteStream, and ReadWriteStream. I believe it to be a fully
> functioning equivalent to NSCollectionStream. If we run the design metrics
> using InternalStream instead of the three other classes we end up with
> metrics that look like this (slightly reformatted from the TeX output):
>
>                                 Squeak  Nile (Squeak-Nile)/Squeak
> Number of Classes And Traits        3      6          -100%
> Number of Classes                   3      1            66%
> Number of Methods                  39     33            15% [*1]
> Number of Bytes                  1328   1078            18%
> Number of Cancelled Methods         0      0             0%
> Number of Reimplemented Methods    10      3            70% [*1]
> Number of Methods Impl. Too High    0      0             0%
>
> [*1] This includes 2 subclassResponsibilities in Squeak which should be
> discounted as pointed out above.
>
> The main differences are in the number of entities as well as in the number
> of methods (overrides). Looking at it in detail it turns out that the larger
> number of entities comes purely from the more fine-grained structure of
> traits (only one class but five traits) and the larger number of methods
> come from overrides where InternalStream has either more efficient versions
> (#upTo: #next: #upToEnd) or needs to compensate PositionableStream assuming
> that the position will be within its readLimit (#position: #setToEnd #reset)
> or implements required subclassResponsibilities (#atEnd, #contents).
>
> It is interesting to see that the traits version can do without most of
> those overrides although it isn't clear to me that this would remain a
> lasting advantage. One could rewrite the Squeak collection hierarchy to do
> without these overrides by relaxing the constraints on PositionableStream
> and use more effective versions by default. This would improve these metrics
> but I'm not sure it is in the spirit of the Squeak collection hierarchy.
>
> That said, I would also slightly refactor NSCollectionStream into, e.g.,
>
> NSPositionableStream <NSTGettableStream + NSPuttableStream +
> NSPositionableStream>
>  NSCollectionStream
>
> The idea in the above refactoring is to keep the "composition class"
> (NSPositionableStream) separate from the "implementation class"
> (NSCollectionStream). It really makes it easier to see what you've done in
> NSCollectionStream and having a class used only to gather the traits also
> makes it more clear that anything you'd implement at that level really
> belongs into a trait and not into the class. It makes looking at classes
> with traits almost bearable ;-)
>
> Cheers,
>  - Andreas
>
>
>
>

> That said, we can now devise a comparison which is more appropriate for
> a Nile vs. Squeak comparison. I've attached a simple class
> InternalStream which as a subclass of PositionableStream implements the
> same folding of ReadStream, WriteStream, and ReadWriteStream. I believe
> it to be a fully functioning equivalent to NSCollectionStream. If we run
> the design metrics using InternalStream instead of the three other
> classes we end up with metrics that look like this (slightly reformatted
> from the TeX output):
>
>                                   Squeak  Nile (Squeak-Nile)/Squeak
> Number of Classes And Traits        3      6          -100%
> Number of Classes                   3      1            66%
> Number of Methods                  39     33            15% [*1]
> Number of Bytes                  1328   1078            18%
> Number of Cancelled Methods         0      0             0%
> Number of Reimplemented Methods    10      3            70% [*1]
> Number of Methods Impl. Too High    0      0             0%
>
> [*1] This includes 2 subclassResponsibilities in Squeak which should be
> discounted as pointed out above.
> The main differences are in the number of entities as well as in the
> number of methods (overrides). Looking at it in detail it turns out that
> the larger number of entities comes purely from the more fine-grained
> structure of traits (only one class but five traits) and the larger
> number of methods come from overrides where InternalStream has either
> more efficient versions (#upTo: #next: #upToEnd) or needs to compensate
> PositionableStream assuming that the position will be within its
> readLimit (#position: #setToEnd #reset) or implements required
> subclassResponsibilities (#atEnd, #contents).

> On Sun, Jun 1, 2008 at 6:13 PM, tim Rowledge <[hidden email]> wrote:
>>
>> On 1-Jun-08, at 2:57 AM, Damien Cassou wrote:
>>>
>>> I've updated the Universe.
>>
>> I don't think it worked. I still see a bunch of idiots running the  
>> place,
>> poverty, irrationality, religiosity, and the sea is just the wrong  
>> shade of
>> pink this time. Please re-try your updating :-)
>
>
> I works for me. I took a 3.10.1 image, opened the Universe Browser,
> updated the list, went to Model Extension, selected Nile 1.0.122 and
> Installed selection.

>
> On 1-Jun-08, at 11:53 PM, Damien Cassou wrote:
>
>> On Sun, Jun 1, 2008 at 6:13 PM, tim Rowledge <[hidden email]>  
>> wrote:
>>>
>>> On 1-Jun-08, at 2:57 AM, Damien Cassou wrote:
>>>>
>>>> I've updated the Universe.
>>>
>>> I don't think it worked. I still see a bunch of idiots running the  
>>> place,
>>> poverty, irrationality, religiosity, and the sea is just the wrong  
>>> shade of
>>> pink this time. Please re-try your updating :-)
>>
>>
>> I works for me. I took a 3.10.1 image, opened the Universe Browser,
>> updated the list, went to Model Extension, selected Nile 1.0.122 and
>> Installed selection.
>
>
> I fear my lame attempt at a joke may have failed. :-(