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

Damien Cassou damien.cassou at gmail.com
Sun May 18 09:05:21 UTC 2008


Thank you for your analyses. I'll have a close look as soon as
possible and will let you know.

On Sat, May 17, 2008 at 10:32 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
>
>
>
>



-- 
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)



More information about the Squeak-dev mailing list