Understanding ruby? need help

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

···

--
Posted via http://www.ruby-forum.com/.

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

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

···

On Feb 18, 2006, at 12:32 PM, bbqbaker wrote:

--
Posted via http://www.ruby-forum.com/\.

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. :slight_smile:

Chris

···

On 2/18/06, bbqbaker <none@noine.com> wrote:

is this kind of right?? thanks

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.

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.

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. :slight_smile:

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

Kind regards

    robert

···

Chris Pine <chris@pine.fm> wrote:

On 2/18/06, bbqbaker <none@noine.com> wrote:

> 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. :slight_smile:

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. :slight_smile:

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. :slight_smile:

Chris

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.

> > I wrote a tutorial that talks, among other things, about a somewhat
> > different approach to understanding blocks and procs:
> >
> > Blocks and Procs - Learn to Program
>
> 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. :slight_smile:

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... :slight_smile:

> 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. :slight_smile:

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. :slight_smile:

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

Kind regards

robert

···

2006/2/22, Chris Pine <chris@pine.fm>:

--
Have a look: Robert K. | Flickr