Eric Mahurin wrote:
> Enumerable says nothing about the return value or each.
> Array.each says it returns an Array, but not what's in that
> Array. Before testing, I was thinking it might be the same
as
> map/collect. The integer loops also say they return an
> integer, but not what it is.You seem to be not so much interested in whether or not
people use this
feature, as instead convincing them that they shouldn't use
them,
because you'd like to see the feature go away.(Which is fine...expressing one's opinions and attempting to
sway
others' it one fine use of the mailing list
I was doing both. I don't like the current behavior and would
like to propose a change, but need to know what the usage is to
see how feasible making a change would be (rendering some code
incompatible).
However, I fail to see as valid the argument that we should
not be
using a feature just because the documentation is incomplete.
Instead,
the documentation should be fixed.There may certainly to be some side-effects of idiosyncracies
of the
language implementation upon which one should not rely, but
that
specific self return value of certain methods smells far more
like an
intentional feature than a bug.Your argument that they should return nil for consistency
certainly has
some merit. I counter-argue that if you're always going to
return the
same value from a method, returning the receiver is usually
preferable
over returning nil.I vote: don't take away my feature just because you don't
like it, and
don't like that I use chaining across blockths which (to
some)
looks
ugly.
If each, each_with_index, downto, upto, step, times, etc
returned nil instead of the original object, it wouldn't be
that difficult to change the code that depended on the original
object returning functionality. For code that would rather
have nil returned, the current functionality forces one to make
a new method for one of these loops or use loop/while/until.
To give more examples, here is how you could write stuff (with
a nil return) like what is in Enumerable (and Array) withod the
need of any more methods:
find(&b): enum.each {|o| break(o) if b.call(o) } -> o or nil
???(&b): enum.each {|o| r=b.call(o) and break(r) } -> r or nil
include?(x): enum.each {|o| break(true) if x==o } -> true or
nil
index(x): enum.each_with_index {|o,i| break(i) if x==o } -> i
or nil
index(&b): enum.each_with_index {|o,i| break(i) if b.call(o) }
-> i or nil
find(&b): m.downto(n) {|i| break(i) if b.call(i) } -> i or nil
...
If each and each_with_index returned nil, you wouldn't need
find, include, and index because you could accomplish the same
thing with each and each_with_index and just 2 more words:
break if. And of course you could do a lot more using whatever
code you want. Another example is that the latest addition to
Array.index to take a block (1.9?) wouldn't be needed. To me,
all of the above code is clearer than find, include, index
because the exact condition checked and what is returned is
shown.
Also, making this change would make these work just like
loop/while/until where they return nil unless a break (with a
value) is done. I think that functionality makes sense and is
useful.
I may have lost this battle already as it appears as though
some are using the current functionality (that doesn't add too
much value). It just may be too late to change this API. But
I wanted to give my 2 cents.
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
···
--- Phrogz <gavin@refinery.com> wrote: