On 6/21/07, Alexander Presber <aljoscha / weisshuhn.de> wrote:

> Obviously breaking compatibilty is a very bad thing.
> But without knowing for sure, I imagine Enumerables implementation
> should have been something more along the lines of the above from the
> beginning.
> (I know, this is a bold claim and I'd like to see more opinions on
> that. But transfires approach is exactly what I was thinking of when
> bringing this up.)
>
> Making Enumerable behave more agnostic to the class it is mixed in
> (by letting the class itself provide a method to add an "element" to
> an instance of itself, Enumerable becomes truly mixable into anything
> that provides "each" and "<<".
> Then doing reject on any class that mixes in Enumerable will yield a
> filtered instance of that class, not Array.
>
> That said - I think there should be no such thing as TomsEnum or any
> special implementation.
> Enumerable is the place to define methods for all things containing
> enumerable elements.
>
> >>
> >> The other option would require an #each_assoc method (maybe assoc
> >> isn't the best term, but anyhow...)
> >>
> >>   module Enumerable
> >>     def select_assoc(&blk)
> >>       h = {}
> >>       each_assoc{|k,v| h[k]=v if blk[k,v]}
> >>       h
> >>     end
> >>   end
> >>
> >> The downside here of course, is twice the number of Enumerable
> >> methods.
> > And although I cannot imagine a case, how do we know that there are
> > not Enumerables that take three or fourtytwo params ;).
> > After all Enumerable is a Mixin and we have to be prepared that it be
> > mixed in, right?
>
> Yes, one could impossibly provide for all possible Mixees like this.
>
> Yours,
> Alex
>
>

A duck is a bird.  It doesn't behave exactly like every other bird you
know about.  But you can be relatively certain it has wings.  I
suspect the least common denominator return of the object is there for
several reasons, including testing, ease of the ruby language
development, etc.  Why the difference for the Hash returning a
different object between select and reject?  I think it's one of those
oversight things.

Thinking about LCD another way, why is it that "13s".to_i gives me 13?
 Because it _mostly_ is an integer.  So, if I have an Enumerable
object that I perform some operation on; where does it say in
duck-typing that I should get an Enumerable object back?

Just by its very nature, duck-typing will forever be laden with
inconsistencies.  The LCD object return is a simple way around it.  I
agree with the general consensus here that #select and #reject should
return the same way for a Hash, but you have to keep in mind that
writing a pragmatic language that does what you want is like trying to
assume everything about you as a programmer before you start typing.
To do that, maybe the designer should be using the LCD for pretty much
everything :)

Todd