Finer-grained modules (like Enumarable) for Collections?

[Its Me]

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).

[url]http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf[/url]

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

Beyond this, there are many other candidates for module-like refactoring
e.g. see Larch traits [url]http://www.cs.iastate.edu/~leavens/Handbooks.html[/url].

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

Cheers ....

[Robert Klemme]

"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).
>
> [url]http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf[/url]
>
> 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

[Mauricio Fernández]

On Sat, Sep 13, 2003 at 02:17:54AM +0900, Robert Klemme wrote:

> > 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.)

This can be leveraged to ease Ruby-in-Ruby or to reimplement the
interpreter: see matju's MetaRuby.


--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

* LG loves czech girls.
<vincent> LG: do they have additional interesting "features" other girls don't have? ;)
-- #Debian