Understanding ruby? need help

[bbqbaker]

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
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

 

[Logan Capaldo]

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
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

 

[Chris Pine]

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=3D10

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

 

[Robert Klemme]

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.

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

Kind regards

robert

 

[Robert Klemme]

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.

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

Ah, I see.

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

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.

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

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