"Its Me" <itsme213hotmail.com> schrieb im Newsbeitrag
news:pLm8b.12869$834.1581twister.austin.rr.com...the> I've been wondering what fine-grained module structure (like Enumerable)
> would make sense for collections, and just came across this work where(for> Smalltalk collections were refactored using somthing they called TraitsInteresting approach. I like these kind of things because they increase> all practical purposes, these are like Ruby modules).
> 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)
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 doentation" and it can mean slower execution.
to> Any thoughts on the benefits / possibility of using some ideas from hereWhile we're at it: I'd suggest to include size and empty? in Enumerable.> provide more fine-grained modules in Ruby libraries?
It would not hurt IMHO and there might be custom collections which can't
implement size and empty? more efficiently than via iterating all