Forum: Ruby code blocks and methods

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.
Ec63907ef47f387aa8309476e05847a8?d=identicon&s=25 andy (Guest)
on 2007-04-08 19:06
(Received via mailing list)
Hi,

I am trying to learn ruby from the following site.

http://www.rubycentral.com/book/index.html

I am familiar with c# and java, one thing I don't understand is the
difference between code blocks and methods, can anyone offer a better
explanation than the one on the site above ?

any help appreciated.
797ef431a5e1295b56c08e1db4c8d2df?d=identicon&s=25 botp (Guest)
on 2007-04-08 19:30
(Received via mailing list)
On 4/9/07, andy <eps@mailinator.com> wrote:
> I am familiar with c# and java, one thing I don't understand is the
> difference between code blocks and methods, can anyone offer a better
> explanation than the one on the site above ?

to quote carlson et al, "a Ruby code block is a method that has no
name." see
http://www.devarticles.com/c/a/Ruby-on-Rails/Code-...
or the ruby cookbook.

kind regards -botp
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-04-08 21:13
(Received via mailing list)
On Mon, Apr 09, 2007 at 02:05:06AM +0900, andy wrote:
> any help appreciated.
As botp pointed out, there really isn't much of a difference between the
two.  The major difference is how they are used.  Essentially, a block
is a method that has no name, is not specifically associated with any
particular object (as far as I'm aware), and can be passed around by
itself as an object (such as "stored in" a variable).

standard method:

  Class Foo
    def method
      # do stuff
    end
  end

  foo = Foo.new
  foo.method

block, used with an iterator:

  bar.each {|baz| # do stuff }

block, "stored in" a variable:

  var = lambda { # do stuff }
  var.call

Of course, you could just as easily use the "do . . . end" syntax for
any of these blocks as the brace-delimited syntax.  Here's the iterator
example again, with the "do . . . end" syntax:

  bar.each do |baz|
    # do stuff
  end

If that doesn't help clear things up (along with the reading recommended
by botp), you might try being more precise in your point of confusion.
I think that should cover your question, though, if it was as general in
scope as it seemed.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-04-08 21:27
(Received via mailing list)
On Mon, Apr 09, 2007 at 04:11:56AM +0900, Chad Perrin wrote:
>
> As botp pointed out, there really isn't much of a difference between the
> two.  The major difference is how they are used.  Essentially, a block
> is a method that has no name, is not specifically associated with any
> particular object (as far as I'm aware), and can be passed around by
> itself as an object (such as "stored in" a variable).

One other thing:

To understand how blocks differ from methods, it might also help to read
about similar constructs in other languages.  For instance, the
difference is analogous (but not identical, because we're talking about
methods rather than functions) to the difference between named functions
and lambdas in several languages.  Another place to look might be the
discussion of named subroutines, callbacks, and closures in the O'Reilly
book Learning Perl (aka The Llama Book) by Randal Schwartz et al.  In
essence, a block in Ruby is something like an anonymous subroutine in
Perl, a proc like a callback, and a proc formed with lexical context
is a closure.

I'm sure someone will disagree with my definition of closure, just based
on the common assertion that all blocks are closures in Ruby, period, so
read up on closures and decide for yourself.  It's helpful in doing so
to think about where the name "closure" originates in this context.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-04-09 01:51
(Received via mailing list)
On 4/8/07, Chad Perrin <perrin@apotheon.com> wrote:
> >
> > any help appreciated.
>
> As botp pointed out, there really isn't much of a difference between the
> two.  The major difference is how they are used.  Essentially, a block
> is a method that has no name,

Not really, blocks are instances of Proc, they are not methods:
irb(main):001:0> def block_class(&b)
irb(main):002:1>   puts b.class
irb(main):003:1>   end
=> nil
irb(main):004:0> block_class {"hello"}
Proc
=> nil
irb(main):005:0> method(:block_class).class
=> Method

Although they are close cousins, and can be substituted for each other
in many contexts.


>  is not specifically associated with any
> particular object (as far as I'm aware),

Not only are blocks associated with a particular object, self is the
receiver of the method which created the block, but also with the
local variables in the execution context of that method when the block
was created.

> and can be passed around by
> itself as an object (such as "stored in" a variable).

So can methods

irb(main):002:0> a = []
=> []
irb(main):003:0> a_get = a.method(:[])
=> #<Method: Array#[]>
irb(main):004:0> a[0] = :fred
=> :fred
irb(main):005:0> a_get.call(0)
=> :fred
irb(main):006:0>

But the pedagogical explanation that a block is an unnamed method is
useful to beginners.
--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-04-09 08:53
(Received via mailing list)
On Mon, Apr 09, 2007 at 08:50:39AM +0900, Rick DeNatale wrote:

[snip a bunch of disagreement with what I said]
>
> But the pedagogical explanation that a block is an unnamed method is
> useful to beginners.

Fair enough.  I defer to the man with the better understanding of Ruby.
Apparently, I missed something somewhere along the way, and I appreciate
getting it cleared up.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-04-09 14:10
(Received via mailing list)
On Apr 8, 2007, at 12:29 PM, botp wrote:

> On 4/9/07, andy <eps@mailinator.com> wrote:
>> I am familiar with c# and java, one thing I don't understand is the
>> difference between code blocks and methods, can anyone offer a better
>> explanation than the one on the site above ?
>
> to quote carlson et al, "a Ruby code block is a method that has no
> name." see http://www.devarticles.com/c/a/Ruby-on-Rails/Code-Blocks-
> and-Iteration/
> or the ruby cookbook.

I wrote about my take on code blocks for my blog a while back:

http://blog.grayproductions.net/articles/2006/01/0...

James Edward Gray II
65f7a8e8c3d59de6f8d858c9f8c04619?d=identicon&s=25 unknown (Guest)
on 2007-04-09 15:28
(Received via mailing list)
I like to think of code blocks as a visitor pattern or a callback
function.
You are essentially passing in a chunk of code to a method to be
executed
for each logical element of data.



             James Edward Gray
             II
             <james@grayproduc
To
             tions.net>                ruby-talk@ruby-lang.org
(ruby-talk
                                       ML)
             04/09/2007 07:46
cc
             AM
                                                                   Subject
                                       Re: code blocks and methods
             Please respond to
             ruby-talk@ruby-la
                  ng.org







On Apr 8, 2007, at 12:29 PM, botp wrote:

> On 4/9/07, andy <eps@mailinator.com> wrote:
>> I am familiar with c# and java, one thing I don't understand is the
>> difference between code blocks and methods, can anyone offer a better
>> explanation than the one on the site above ?
>
> to quote carlson et al, "a Ruby code block is a method that has no
> name." see http://www.devarticles.com/c/a/Ruby-on-Rails/Code-Blocks-
> and-Iteration/
> or the ruby cookbook.

I wrote about my take on code blocks for my blog a while back:

http://blog.grayproductions.net/articles/2006/01/0...

James Edward Gray II



.
This message and any attachments contain information from Union Pacific
which may be confidential and/or privileged.
If you are not the intended recipient, be aware that any disclosure,
copying, distribution or use of the contents of this message is strictly
prohibited by law. If you receive this message in error, please contact
the sender immediately and delete the message and any attachments.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-04-09 15:58
(Received via mailing list)
On 4/9/07, DDENNISON@up.com <DDENNISON@up.com> wrote:
> I like to think of code blocks as a visitor pattern or a callback function.
> You are essentially passing in a chunk of code to a method to be executed
> for each logical element of data.

That's more a description of how they are used in iterator methods
rather than a general description of code blocks and the variety of
ways they can be used.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
1c0cd550766a3ee3e4a9c495926e4603?d=identicon&s=25 John Joyce (Guest)
on 2007-04-09 17:01
(Received via mailing list)
Ruby blocks are generally far simpler than they seem at first.
797ef431a5e1295b56c08e1db4c8d2df?d=identicon&s=25 botp (Guest)
on 2007-04-09 19:03
(Received via mailing list)
On 4/9/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> Not really, blocks are instances of Proc, they are not methods:
> irb(main):001:0> def block_class(&b)

i hope we don't generalize that much. Here eg, we are explicitly
converting a block to a proc.

> But the pedagogical explanation that a block is an unnamed method is
> useful to beginners.

i prefer to refer to blocks as just mere codes that cannot stand on
their own yet. They have to be proc-ified or lamba-fied or yielded as
code blocks in methods.

but I really hoped that methods, procs, and lambdas be unified.  Their
functions look very similar.

kind regards -botp
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2007-04-09 20:08
(Received via mailing list)
botp wrote:
> i prefer to refer to blocks as just mere codes that cannot stand on
> their own yet. They have to be proc-ified or lamba-fied or yielded as
> code blocks in methods.

You are right. Blocks are not even objects, just syntactical constructs
which can potentially be associated with an object using Proc.new,
#proc, #lambda, or the & notation. Yielding to a block doesn't cause any
such object to be instantiated.

There is a small performance cost to this instantiation, so in general I
try to write methods like this:

def foo; ... yield(something) ...; end

rather than

def foo(&bl); ... bl.call(something); end

Sometimes, though, you really need to instantiate a block and store it
somewhere so it persists between method calls.

Another advantage of yield is that RDoc can automatically recognize it
and document it.
6087a044557d6b59ab52e7dd20f94da8?d=identicon&s=25 Peña, Botp (Guest)
on 2007-04-10 06:17
(Received via mailing list)
From: Joel VanderWerf [mailto:vjoel@path.berkeley.edu] :
# Another advantage of yield is that RDoc can automatically
# recognize it and document it.

hmmm, i did not know that.
thanks for the tip, joel.

kind regards -botp
This topic is locked and can not be replied to.