On Feb 4, 1:20 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:


> I'm not talking intuitive vs. non-intuitive (it's far too subjective),
> I'm talking the current documented (and implemented!) behavior.
> Remember that Enumerable is a contract, and code dealing with an
> Enumerable may not happen to know that it's dealing with a Hashy kind
> of Enumerable. :-)
> I do agree -- not that it matters! ;-) -- that for (say) 2.0, an
> argument can be made for changing Enumerable to say that for these
> kinds of methods, it returns an Enumerable (not an Array), and that
> concrete classes should (where appropriate) return the same type as
> the original.  But (due respect to kangax) to me that's not a bug,
> that's a request for API enhancement, and not the kind of thing to do
> in a dot release or by making Hash a special case.

Agreed. Bug or not bug, but we can't make this change without breaking
backwards compatibility (just like we can't change form serialization
to return an array, rather than an object - to preserve an order, as
per specs; just like we can't rename `Element#wrap` which conflicts
with textarea elements' "wrap" property in MSHTML DOM; just like we
can't remove somewhat useless global `ObjectRange` and other, barely
used globals) : )

Having said that, it always seemed unintuitive to me how enumerable
integrates with hashes. Apparently, Ruby creators/users found this
confusing as well. Just like all of the enumerable methods delegate
its enumeration logic to Hash's "_each" (which enumerates over *all*
keys, not just numeric ones as `Array.prototype._each` does), the
logic of return value should be delegated to Hash too (imo) : )

You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to