From: Robert Klemme <bob.news@...>
Date: 2003-09-13T02:17:54+09:00
Subject: Re: Finer-grained modules (like Enumarable) for Collections?


"Its Me" <itsme213@hotmail.com> schrieb im Newsbeitrag
news:pLm8b.12869$834.1581@twister.austin.rr.com...
> I've been wondering what fine-grained module structure (like Enumerable)
> would make sense for collections, and just came across this work where
the
> Smalltalk collections were refactored using somthing they called Traits
(for
> all practical purposes, these are like Ruby modules).
>
> http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf
>
> There were some very useful ideas in this re-factoring. e.g.
>
> module TEmptiness
>    #requires "size"
>    def isEmpty () ...
>    def notEmpty () ...
>    def ifEmpty (&block)
>    def ifNotEmpty (&block)
>     etc.
> end

Interesting approach.  I like these kind of things because they increase
modularity and improve reusability though I can't comment on efficiency
issues with Ruby in this case.  (We'd get lot's of modules that are
included in Enumerable which in turn is included in std collection types.)

The question remains whether it is worthwile.  Because of Ruby's nature it
does not hurt to include Enumerable - even if it would depend on more than
just a single method and not all of these methods were present.  IMHO the
small gain would be expressions like "obj.kind_of? TEmptiness" but we'd
get a lot more modules at the same time.  This need not necessary mean
"more readable documentation" and it can mean slower execution.

> Any thoughts on the benefits / possibility of using some ideas from here
to
> provide more fine-grained modules in Ruby libraries?

While we're at it: I'd suggest to include size and empty? in Enumerable.
It would not hurt IMHO and there might be custom collections which can't
implement size and empty? more efficiently than via iterating all
elements.

Regards

    robert