Forum: Ruby Understanding ruby? need help

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8f59cd4edf122212b71e41dfb36fa55e?d=identicon&s=25 bbqbaker (Guest)
on 2006-02-18 18:32
I hi,
I am new to ruby and bought my first book. i am having sort of difficult
time understanding blocks/yeild statements. i am coming from C++.

class Array
  def find
    for i in 0..size
      value = self[i]
      return value if yield(value)
    end
    return nil
  end
end

[1,3,5,7,9].find {|v| v*v > 30}



-> 7

in the last line of code, it is passing to function find each number one
by one thats on the left? when it hits the "return value if
yield(value)" it will pass parameter value to the block and v will now
be equal to value, and then perform the code v*v > 30. if that is true,
it will get out of fuction find.


so what is in between the |" "| of the block is like in c++:

bool code_blk(int v)
{
  if (v * v > 30)
    return TRUE;
  else
    return FALSE;
}

is this kind of right?? thanks
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-02-18 22:41
(Received via mailing list)
On Feb 18, 2006, at 12:32 PM, bbqbaker wrote:

>     end
> in the last line of code, it is passing to function find each
> bool code_blk(int v)
> {
>   if (v * v > 30)
>     return TRUE;
>   else
>     return FALSE;
> }
>
> is this kind of right?? thanks
>

Basically yes:

however if I was writing in C++ I'd probably say:

bool code_blk(int v)
{
    return v * v > 30;
}

the extra branch is really unecessary
B464ff27d7d3b0750a7bfe2717c49d2d?d=identicon&s=25 Chris Pine (Guest)
on 2006-02-19 11:02
(Received via mailing list)
On 2/18/06, bbqbaker <none@noine.com> wrote:
> is this kind of right?? thanks

Yep, that's basically it.  Coming from C++, I also had a tough time
with blocks at first (but they are so great, so it's worth the
effort).

I wrote a tutorial that talks, among other things, about a somewhat
different approach to understanding blocks and procs:

  http://pine.fm/LearnToProgram/?Chapter=10

and, of course, it's also covered in my book:

  http://www.pragmaticprogrammer.com/titles/fr_ltp/

(The book covers what's in the tutorial, but considerably more in
depth, and with the benefit of the feedback I got from the tutorial
(which came first), as well as covering things that never made it into
the tutorial.)

Essentially, what I found confusing was "yield".  Once you look at the
problem from the angle of little functions (like the C++ function you
wrote) that you pass around explicitly, it makes more sense (to me, at
least).

Once I wrapped my head around that, it wasn't hard to see yield and
the "do |...| code-code-code end" syntax as just shortcuts to make the
whole process easier to program.

And for the record, I still think "yield" is a weird name for it.  :)

Chris
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-02-19 11:38
(Received via mailing list)
Chris Pine <chris@pine.fm> wrote:
> On 2/18/06, bbqbaker <none@noine.com> wrote:
>> is this kind of right?? thanks
>
> Yep, that's basically it.  Coming from C++, I also had a tough time
> with blocks at first (but they are so great, so it's worth the
> effort).

C++ might want to compare blocks with functors.  I like to think of them
as
anonymous functions with a closure.  Often the closure is't even needed,
such in simple examples where the block only operates on its arguments.

> I wrote a tutorial that talks, among other things, about a somewhat
> different approach to understanding blocks and procs:
>
>   http://pine.fm/LearnToProgram/?Chapter=10

Chris, I can't see "yield" mentioned on that page.  Is it just me, did I
overlook it?  Is this intentionally?  I mean, "yield" would be the first
thing that I'd describe on such a page; IMHO it's the default way to go
when
passing blocks to methods (it's also the fastest AFAIK).  I only use
&block
if I have to store the block in a variable and / or have to pass it on
to
another (recursive) method call.

> problem from the angle of little functions (like the C++ function you
> wrote) that you pass around explicitly, it makes more sense (to me, at
> least).
>
> Once I wrapped my head around that, it wasn't hard to see yield and
> the "do |...| code-code-code end" syntax as just shortcuts to make the
> whole process easier to program.

If you look at the block as anonymous function it's clear that one needs
a
special syntax to invoke it (can't use the name).  That's exactly what
"yield" does.

> And for the record, I still think "yield" is a weird name for it.  :)

OTOH this has the advantage of drawing people's attention to it which
probably makes reading code easier. :-)

Kind regards

    robert
B464ff27d7d3b0750a7bfe2717c49d2d?d=identicon&s=25 Chris Pine (Guest)
on 2006-02-22 16:19
(Received via mailing list)
> > I wrote a tutorial that talks, among other things, about a somewhat
> > different approach to understanding blocks and procs:
> >
> >   http://pine.fm/LearnToProgram/?Chapter=10
>
> Chris, I can't see "yield" mentioned on that page.  Is it just me, did I
> overlook it?  Is this intentionally?

Yep.  On the next page (Chapter=11), I talk about, among other things,
yield.  But I wanted to bring it in later as another way of doing it.


> I mean, "yield" would be the first
> thing that I'd describe on such a page; IMHO it's the default way to go when
> passing blocks to methods (it's also the fastest AFAIK).

Default way to go for an experienced programmer to use?  Or for a
non-programmer to learn?  Very different situations.  :)


> I only use &block
> if I have to store the block in a variable and / or have to pass it on to
> another (recursive) method call.

Me, too... unless I'm teaching someone about it, because "yield" just
throws people off in my experience (not just my personal experience,
but my experience in teaching others).


> If you look at the block as anonymous function it's clear that one needs a
> special syntax to invoke it (can't use the name).  That's exactly what
> "yield" does.

Well, there's "anonymous" (like &block), and then there's *invisible*,
like what yield is calling.  There's a big difference.  I'm just
trying to make it visible, which is an important step on the way to
understandable.

Plus, passing a function around, and calling a function... these
things are extensions of what the reader has already learned at that
point.  "yield" is something totally new.  Better to describe this in
terms of something the reader is more familiar with first; then I can
just say "yield is a magical shortcut".  Because it sort of it, right?
 It's magical, and magical is (among other things) weird.  That's my
hypothesis, anyway.  :)

Yield:  it's something you do to traffic with the right of way.  It's
how many cookies your recipe is "supposed" to make if you don't eat
any of the dough.  I can see the (imho, weak) analogy to
programming... but I think that describing what is going on in as
plain of terms as possible is the best way to teach this.

In any case, the PickAxe does it the other way, so hopefully we have
every learning style covered.  :)

Chris
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-02-24 17:39
(Received via mailing list)
Sorry for the late reply.  Apparently your posting didn't make it to
the news group (yet).  I start getting really annoyed by this half
working gateway.

2006/2/22, Chris Pine <chris@pine.fm>:
> > > I wrote a tutorial that talks, among other things, about a somewhat
> > > different approach to understanding blocks and procs:
> > >
> > >   http://pine.fm/LearnToProgram/?Chapter=10
> >
> > Chris, I can't see "yield" mentioned on that page.  Is it just me, did I
> > overlook it?  Is this intentionally?
>
> Yep.  On the next page (Chapter=11), I talk about, among other things,
> yield.  But I wanted to bring it in later as another way of doing it.

Ah, I see.

> > I mean, "yield" would be the first
> > thing that I'd describe on such a page; IMHO it's the default way to go when
> > passing blocks to methods (it's also the fastest AFAIK).
>
> Default way to go for an experienced programmer to use?  Or for a
> non-programmer to learn?  Very different situations.  :)

I can only speak from my experience: I learned yield earlier and the
only thing I found difficult about it that I couldn't figure how to
pass a block on to some other method. I knew there had to be a way but
the manual forwarding with a block seemed to awkward... :-)

> things are extensions of what the reader has already learned at that
> point.  "yield" is something totally new.  Better to describe this in
> terms of something the reader is more familiar with first; then I can
> just say "yield is a magical shortcut".  Because it sort of it, right?
>  It's magical, and magical is (among other things) weird.  That's my
> hypothesis, anyway.  :)

Sounds quite reasonable.  I never looked at it this way - and never
experienced similar problems (probably because I never gave a Ruby
class :-)).

The way I'd do it is explain if you have a method that accepts a block
use yield to invoke it. Yield is like a function call, arguments are
passed on to the block and the block's return value is returned from
yield. Oh, and btw. if you want to store that block, pass it on to
another method or change it's scope with instance_eval you can access
it directly by adding &block at the end of the method's argument list
like this: <example>

> In any case, the PickAxe does it the other way, so hopefully we have
> every learning style covered.  :)

Now we just need some magic that will direct novices to the source
appropriate for their learning style. :-))

Kind regards

robert
This topic is locked and can not be replied to.