Yield Example in Ruby For Rails book

rubyonrails-talk
1

Thank you for your explanation. It works!!! I don't know why any of the authors who write Ruby books use Java and the known concepts to learn this new language. It is much easier to learn that way.

So this block thingy is kinda like anonymous classes?

Rails for Java developers is in beta, who is writing Ruby for Java Developers?

2

Hi --

3

I'll change my mind when someone writes Java for Ruby Developers :slight_smile:

David your book is kinda like a good wine. It is getting better as it ages on my Mac. I am reading it the second time slowly and also running the examples. I understood your explanation about blocks, scopes etc. But only when I run the examples my brain is able to fully absorb the material in the book.

4

Hi --

I'll change my mind when someone writes Java for Ruby Developers :slight_smile:

David your book is kinda like a good wine. It is getting better as it ages on my Mac. I am reading it the second time slowly and also running the examples. I understood your explanation about blocks, scopes etc. But only when I run the examples my brain is able to fully absorb the material in the book.

That's fine -- it's all part of it. Running the examples isn't "cheating" :slight_smile:

I'm glad you're liking it.

David

5

Hi --

Bala Paranj wrote:

So this block thingy is kinda like anonymous classes?

In principle they are anonymous *methods* rather than *classes*. If you think of them like that it should be easier to understand what's going on when you pass arguments into them and these arguments initialize the block variables between the upright bars (like |cel| in the example above).

Thinking of them as methods has some pitfalls, though, since methods always live in modules or classes and blocks don't.

Blocks are kind of oddities (in my view!) in Ruby, however, as they aren't objects. True, they can be wrapped up inside objects (Procs) but that doesn't alter the fact that a block itself has no independent existence. This contrasts with some other object oriented languages - notably Smalltalk - in which a block is an object with its own methods. Ask a standalone Smalltalk block to tell you its class and it will reply that it is an instance of Block (or BlockClosure). Ask a standalone Ruby block to tell you its class - e.g.

puts( {|cel| cel * 9 / 5 + 32}.class )

...and Ruby replies:

parse error, unexpected '|', expecting '}' puts( {|cel| cel * 9 / 5 + 32}.class )

However, I may be straying into arcane areas here :wink:

I think the best way to look at blocks is as a part of the syntax of the Ruby method call:

   [receiver dot] method_name [arg_list] [block]

Informally one does speak of blocks as anonymous functions, rather than saying "a syntactic construct that gets wrapped in a Proc" (or whatever). But it's useful to keep the distinction in view that they start life as syntax.

On that construction, a block is a kind of sibling to the argument list -- and, in both cases, they're pure syntax: there's no Block class and no ArgumentList class. Also in both cases, the method can grab what's there and stash it in a variable:

      m(a,b,c) { puts "hi" }         > > > >   def m(x,y,z,&block)

In a sense, the &block thing is really a completely separate transaction from the x,y,z part; it might almost be represented as:

   def m(x,y,z) {&block}

or something. (I'm not advocating that, just making the point that the block and &block are going on in parallel to, rather than as part of, the passing of arguments.)

David

6

Hi --

I must say that I have problems with making Ruby's blocks fit comfortably into the Ruby universe. The arguments in an argument list act as the receivers of the arguments passed in the 'message' sent to that method. These formal arguments are therefore, as you say, 'pure syntax'.

I meant the argument list that's part of the method call (rather than the method). I should probably be saying parameter instead of argument or something... but basically the (a,b,c) in meth(a,b,c).

However, the objects to which the arguments are instantiated are *not* mere syntax. They have a 'real' self-contained existence as instances of Ruby classes. Blocks, on the other hand, do not have such an existence.

I must say that I am very much prejudiced in favour of the Smalltalk version of blocks (instances of a Block or Closure class) as that simply seems to me to be consistent with the pure OOP paradigm.

I believe that there was a Block class in CVS head two or three years ago, for about a week :slight_smile: I further remember that its existence had something to do with my having lobbied for it, though I can't remember the sequence in detail. It was a period when there was a lot of discussion of the weirdnesses of Proc/proc/lambda/block/method. The discussion doesn't seem to be as lively any more, though at least some of the weirdness is still there :slight_smile:

David

7

This is a very good observation. You said in the book that one of the advantages of the blocks is that they can be combined in many ways. I did not find any example of how you would combine it.

I am not clear on how you would combine it since it is not part of a class or module.