Asp Forum - Re: object loops and what they return

Eric Mahurin

5/11/2005 10:28:00 PM

That sure looks ugly. I don't see any advantage of this over:

my_array.each do |item|
puts "item"
end
if my_array.empty?
puts "(no items found)"
end

What you have below doesn't look to readable and it is using
undocumented behavior (the docs don't say what each returns
only that it is an enumeration). In ruby 1.6 docs, it says
that each_with_index returns nil and now it returns the object.

> Yes. Not often, but occasionally the return value is useful.
>
> For example, there was a solution like this posted to the
> rails mailing list, on how to iterate over all the items in a
> record, or print out a 'no records found' type line if none
> existed:
>
> if my_array.each do |item|
> puts "item"
> end.empty?
> puts "(no items found)"
> end
>
> ________________________________
>
> From: Eric Mahurin [mailto:eric_mahurin@yahoo.com]
> Sent: Wed 5/11/2005 3:31 PM
> To: ruby-talk ML
> Subject: Re: object loops and what they return
>
>
>
> > > Consider these loops:
> > >
> > > <object>.<loop-method> { <code> }
> > >
> > > where loop method is each, each_with_index, upto, downto,
> > step,
> > > and probably others.
> > >
> > > Although it is not documented, all of these look to
> return
> > the
> > > origninal object (collection or int). Does anybody find
> > this
> > > useful?? If not, I would propose that these return nil
> > just
> > > like loop, while, until, begin/end while, and begin/end
> > until.
> > > I've never found the return value of these methods
> useful,
> > but
> > > I have found the the built-in loops returning nil useful.
> > Here
> > > are a couple:
> > >
> > > # find first index where you find the object obj in array
> > > index = array.each_with_index do |i,x|
> > > break(i) if obj.equal?(x)
> > > end
> > >
> > > # find last index where you find the object obj in array
> > > index = (array.size-1).downto(0) do |i,x|
> > > break(i) if obj.equal?(x)
> > > end
> >
> > >> a=%w{a b c d e f g ab c}
> > => ["a", "b", "c", "d", "e", "f", "g", "ab", "c"]
> > >> a.index "c"
> > => 2
> > >> a.rindex "c"
> > => 8
> > >> a.index "foo"
> > => nil
>
> I was wanting to compare the objects with equal? (compares
> object ids) not == (what index/rindex use).
>
> > > The problem with the above now is that index will be the
> > loop
> > > object (array and array.size-1 from above) when you don't
> > find
> > > the obj. Instead of the above, I end up using old-style
> > loops
> > > to accomplish what I want.
> > >
> > > With "each" returning nil, you can also see that many of
> > the
> > > derived loops in Enumerable become trival almost to where
> > you
> > > don't need them.
> >
> > Interesting aspect. I assume the return behavior is from a
> > time where break
> > could not return a value so your constructions weren't
> > possible.
> >
> > Typically I put such functionality into methods and then I
> > use "return" to
> > short circuit:
> >
> > module Enumerable
> > def find_pos(x)
> > each_with_index {|e,i| return i if x == e}
> > nil
> > end
> >
> > def find_cond
> > each_with_index {|e,i| return i if yield e}
> > nil
> > end
> > end
>
> The loops I describe above were in some method. I didn't
> want
> to create a new method just for those loops. That would be
> kind of silly. I used traditional loops instead. Also, with
> what I am proposing you wouldn't need the "nil" in the above
> 2
> methods.
>
> Does anybody find a use for these loop methods returning the
> original object (undocumented) instead of nil (like other
> loops)? If not, I would like to make an RCR for this.
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.co...
>
>
>
>

__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/...

40 Answers

Gavin Kistner

5/11/2005 11:39:00 PM

Eric Mahurin wrote:
> That sure looks ugly. I don't see any advantage of this over:
>
> my_array.each do |item|
> puts "item"
> end
> if my_array.empty?
> puts "(no items found)"
> end

*shrug* I personally prefer what I posted over this. (I tend to use {
and } for blocks instead of begin/end in my own code because IMHO it
visually groups it better, but I used begin/end here since that seems
to be the emerging multi-line choice of the community.)

> What you have below doesn't look to readable and it is using
> undocumented behavior (the docs don't say what each returns
> only that it is an enumeration). In ruby 1.6 docs, it says
> that each_with_index returns nil and now it returns the object.

As I noted in another response, a lack of documentation calls for
fixing the documentation (as is needed in more than a few places in
Ruby), not for not using the method fully.

And that the behavior of this--and other like-minded--methods has
changed between 1.6 and 1.8 is not unique among aspects of Ruby. Just
'cause it changed, don't mean it broke. :)

dblack

5/11/2005 11:58:00 PM

Brian Schröder

5/12/2005 7:48:00 AM

On 12/05/05, Phrogz <gavin@refinery.com> wrote:
> Eric Mahurin wrote:
> > That sure looks ugly. I don't see any advantage of this over:
> >
> > my_array.each do |item|
> > puts "item"
> > end
> > if my_array.empty?
> > puts "(no items found)"
> > end
>
> *shrug* I personally prefer what I posted over this. (I tend to use {
> and } for blocks instead of begin/end in my own code because IMHO it
> visually groups it better, but I used begin/end here since that seems
> to be the emerging multi-line choice of the community.)
> [snip]

I just wanted to throw in that I'm in the camp of people who use begin
end when the side effect is important and braces when the return value
is important. This conveys more meaning on a causual glance. I.e.

print "100!"
puts (1..100).inject(1) { | r, i |
r*i
}

(1..100).inject(1) do | r, i |
puts "#{i}! = #{r = r*i}"
end

regards,

Brian Schröder

--
http://ruby.brian-sch...

Stringed instrument chords: http://chordlist.brian-sch...

Gavin Kistner

5/12/2005 12:42:00 PM

On May 12, 2005, at 1:48 AM, Brian Schröder wrote:
> On 12/05/05, Phrogz <gavin@refinery.com> wrote:
>> I tend to use {
>> and } for blocks instead of begin/end in my own code because IMHO it
>> visually groups it better, but I used begin/end here since that seems
>> to be the emerging multi-line choice of the community.)
>
> I just wanted to throw in that I'm in the camp of people who use begin
> end when the side effect is important and braces when the return value
> is important.

I had no idea that there was such a camp. I like that.

Can I come hang out in your camp? I'll bring my own sleeping bag and
marshmallows.

Brian Schröder

5/12/2005 1:22:00 PM

On 12/05/05, Gavin Kistner <gavin@refinery.com> wrote:
> On May 12, 2005, at 1:48 AM, Brian Schröder wrote:
> > On 12/05/05, Phrogz <gavin@refinery.com> wrote:
> >> I tend to use {
> >> and } for blocks instead of begin/end in my own code because IMHO it
> >> visually groups it better, but I used begin/end here since that seems
> >> to be the emerging multi-line choice of the community.)
> >
> > I just wanted to throw in that I'm in the camp of people who use begin
> > end when the side effect is important and braces when the return value
> > is important.
>
> I had no idea that there was such a camp. I like that.
>
> Can I come hang out in your camp? I'll bring my own sleeping bag and
> marshmallows.
>

In this case you're welcome. I know I read this in two independent
blog entries, but I can't find them now. So I imagine i do not really
own this camping site ;-)

best regards,

Brian

--
http://ruby.brian-sch...

Stringed instrument chords: http://chordlist.brian-sch...

Robert Klemme

5/12/2005 1:34:00 PM

Brian Schröder wrote:
> On 12/05/05, Gavin Kistner <gavin@refinery.com> wrote:
>> On May 12, 2005, at 1:48 AM, Brian Schröder wrote:
>>> On 12/05/05, Phrogz <gavin@refinery.com> wrote:
>>>> I tend to use {
>>>> and } for blocks instead of begin/end in my own code because IMHO
>>>> it visually groups it better, but I used begin/end here since that
>>>> seems to be the emerging multi-line choice of the community.)
>>>
>>> I just wanted to throw in that I'm in the camp of people who use
>>> begin end when the side effect is important and braces when the
>>> return value is important.
>>
>> I had no idea that there was such a camp. I like that.
>>
>> Can I come hang out in your camp? I'll bring my own sleeping bag and
>> marshmallows.
>>
>
> In this case you're welcome. I know I read this in two independent
> blog entries, but I can't find them now. So I imagine i do not really
> own this camping site ;-)

If you got thrown out you can come over to my camp ("it's on one line ?
use braces : use 'do ... end'") - we have plenty of space over here. As
you can see I also frequently visit the ternary operator camp...
;-)

Kind regards

robert

<space>

</space>

Michel Martens

5/12/2005 2:13:00 PM

On 5/12/05, Robert Klemme <bob.news@gmx.net> wrote:
> Brian Schröder wrote:
> > On 12/05/05, Gavin Kistner <gavin@refinery.com> wrote:
> >> On May 12, 2005, at 1:48 AM, Brian Schröder wrote:
> >>> On 12/05/05, Phrogz <gavin@refinery.com> wrote:
> >>>> I tend to use {
> >>>> and } for blocks instead of begin/end in my own code because IMHO
> >>>> it visually groups it better, but I used begin/end here since that
> >>>> seems to be the emerging multi-line choice of the community.)
> >>>
> >>> I just wanted to throw in that I'm in the camp of people who use
> >>> begin end when the side effect is important and braces when the
> >>> return value is important.
> >>
> >> I had no idea that there was such a camp. I like that.
> >>
> >> Can I come hang out in your camp? I'll bring my own sleeping bag and
> >> marshmallows.
> >>
> >
> > In this case you're welcome. I know I read this in two independent
> > blog entries, but I can't find them now. So I imagine i do not really
> > own this camping site ;-)
>
> If you got thrown out you can come over to my camp ("it's on one line ?
> use braces : use 'do ... end'") - we have plenty of space over here. As
> you can see I also frequently visit the ternary operator camp...
> ;-)

We are on the same camp. I'm the one who also uses the ternary
operator but doesn't like how it fits with question-mark methods
(@camp.nil? ? 'nil?' : @camp.empty? ? 'empty?' : '!') because it
sounds too intriguing.

Michel.

Gavin Kistner

5/12/2005 2:13:00 PM

On May 12, 2005, at 7:35 AM, Robert Klemme wrote:
> If you got thrown out you can come over to my camp ("it's on one
> line ?
> use braces : use 'do ... end'") - we have plenty of space over
> here. As
> you can see I also frequently visit the ternary operator camp...

I like the ternary folks, we hang out quite a bit.

But you single-line/multi-line folks are...well...odd.

I've never seen so many people eat marshmallows as well as pork and
beans at the same time.

dblack

5/12/2005 2:25:00 PM

Gavin Kistner

5/12/2005 2:29:00 PM

On May 12, 2005, at 8:24 AM, David A. Black wrote:
> I know, it's not 100% reliable... but it suggests that, at least
> roughly, 3% of 'do' blocks end on the same line, while 62% of {}
> blocks end on the same line. So this "odd" behavior is actually
> pretty canonical :-)

Yup...I see that the standard code and the community have somewhat
decided upon this convention. When I write code that I'll be
releasing into the wild, I've recently been trying it out (just like
I change my tabs to 2-spaces before publishing). But I hate it :)

comp.lang.ruby

Re: object loops and what they return

Eric Mahurin

Gavin Kistner

dblack

Brian Schröder

Gavin Kistner

Brian Schröder

Robert Klemme

Michel Martens

Gavin Kistner

dblack

Gavin Kistner

x Login to ForumsZone