code blocks and methods

Discussion in 'Ruby' started by andy, Apr 8, 2007.

  1. andy

    andy Guest

    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.

    --
    Eps
     
    andy, Apr 8, 2007
    #1
    1. Advertising

  2. andy

    botp Guest

    On 4/9/07, andy <> 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.

    kind regards -botp
     
    botp, Apr 8, 2007
    #2
    1. Advertising

  3. andy

    Chad Perrin Guest

    On Mon, Apr 09, 2007 at 02:05:06AM +0900, andy wrote:
    > 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.


    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.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Ben Franklin: "As we enjoy great Advantages from the Inventions of
    others we should be glad of an Opportunity to serve others by any
    Invention of ours, and this we should do freely and generously."
     
    Chad Perrin, Apr 8, 2007
    #3
  4. andy

    Chad Perrin Guest

    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.

    --
    CD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "The measure on a man's real character is what he would do
    if he knew he would never be found out." - Thomas McCauley
     
    Chad Perrin, Apr 8, 2007
    #4
  5. On 4/8/07, Chad Perrin <> wrote:
    > On Mon, Apr 09, 2007 at 02:05:06AM +0900, andy wrote:
    > > 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.

    >
    > 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/
     
    Rick DeNatale, Apr 9, 2007
    #5
  6. andy

    Chad Perrin Guest

    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.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    "Real ugliness is not harsh-looking syntax, but having to
    build programs out of the wrong concepts." - Paul Graham
     
    Chad Perrin, Apr 9, 2007
    #6
  7. On Apr 8, 2007, at 12:29 PM, botp wrote:

    > On 4/9/07, andy <> 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/05/code-as-a-data-type

    James Edward Gray II
     
    James Edward Gray II, Apr 9, 2007
    #7
  8. On 4/9/07, <> 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/
     
    Rick DeNatale, Apr 9, 2007
    #8
  9. andy

    John Joyce Guest

    Ruby blocks are generally far simpler than they seem at first.
    On Apr 9, 2007, at 10:57 PM, Rick DeNatale wrote:

    > On 4/9/07, <> 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/
    >
     
    John Joyce, Apr 9, 2007
    #9
  10. andy

    botp Guest

    On 4/9/07, Rick DeNatale <> 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
     
    botp, Apr 9, 2007
    #10
  11. 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.

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
     
    Joel VanderWerf, Apr 9, 2007
    #11
  12. andy

    Peña, Botp Guest

    From: Joel VanderWerf [mailto:] :
    # Another advantage of yield is that RDoc can automatically=20
    # recognize it and document it.

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

    kind regards -botp
     
    Peña, Botp, Apr 10, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arjen
    Replies:
    3
    Views:
    460
    Scott Allen
    Feb 27, 2005
  2. John Rivers
    Replies:
    29
    Views:
    889
    Kevin Spencer
    Sep 7, 2005
  3. Igor Maximchuk

    Methods written in C and code blocks

    Igor Maximchuk, Feb 17, 2004, in forum: Ruby
    Replies:
    2
    Views:
    105
    ch00k
    Feb 18, 2004
  4. matt
    Replies:
    1
    Views:
    287
    George Ogata
    Aug 6, 2004
  5. Steven Taylor
    Replies:
    9
    Views:
    276
    Brian Candler
    Apr 27, 2009
Loading...

Share This Page