From: "David A. Black" Date: 2008-05-28T02:36:26+09:00 Subject: Re: OOP in Ruby? Hi -- On Wed, 28 May 2008, Huw Collingbourne wrote: > Robert Dober wrote: > >> Anyway, I will tell you what is important to me: >> Blocks in Ruby are Proc objects, always, can you agree with this >> statement, > > No, it doesn't seem to me that they are. As I said before, in Ruby a > block does not, by default, have its own independent existence. Let me > illustrate by comparison with Smalltalk. When we write blocks and use > them with methods (e.g. times in Ruby or timesRepeat: in Smalltalk) they > may appear to be more or less the same: [snip] > It's a subtle point, I know, and I don't want to make any big deal of > it. After all, when a Proc object block is explicitly created from a > Ruby block, it works in a comparable way to a Smalltalk block. However, > that doesn't alter the fact that, in Ruby, blocks (chunks of code > delimited by {..} or do..end) are not normally instances of the Proc > class. They are, well, just chuncks of code but not objects. To > demonstrate that, try evaluating a block: I agree that this subtle point is important. It's one of these things where it seems like splitting hairs to say that the code block is syntax and the Proc is an object, but if one doesn't make that distinction, then there's a kind of off-by-one condition later on, when things like Proc.new taking a block starts to seem weird (why would Proc.new take a Proc?). It's similar, I think, to hair-splitting between "message-sending" and "method-calling". Much of the time it doesn't matter, but if there's no separation of the terminology, then the very concept of sending an object a message it can't map to a method gets harder, rather than easier, to grasp. David -- Rails training from David A. Black and Ruby Power and Light: INTRO TO RAILS June 9-12 Berlin ADVANCING WITH RAILS June 16-19 Berlin INTRO TO RAILS June 23-26 London (Skills Matter) See http://www.rubypal.com for details and updates!