From: "Hal E. Fulton" Date: 2003-04-26T13:30:13+09:00 Subject: Re: block.call vs. yield ----- Original Message ----- From: To: "ruby-talk ML" Sent: Friday, April 25, 2003 11:08 PM Subject: Re: block.call vs. yield > > |'yield' as a method name for blocks strikes me as awkward. In the > > |past I've never thought of 'yield'ing as an action performed by > > |blocks, nor as something they're asked to do; it's more that they are > > |executed because they get control because a 'yield' has already > > |happened. > > > > Sorry I don't understand. Do you mean you don't want a method with > > reserved word name? > > What I got from David's comment, and what the word 'yield' suggests to me, > is that a block itself does not yield, but rather a block is executed because > some other process has opted to yield process control. > > For example, when driving in the States (and I imagine there is something > similar elsewhere) there are signs that say, 'Yield', meaning one driver > must pause and allow other drivers to proceed. The pausing driver > is the one processing the 'yield' message, rather than those drivers given > the go-ahead. Just to throw in my opinion: I'm not sure this is what David was saying, but the use of the word 'yield' was counter-intuitive to me when I was learning Ruby. I thought it was used in the sense of "produce" -- yield a result, produce a result. So I expected to be like a "return" statement. I would have chosen a word like "invoke" instead. But I think the rationale is that you "yield" control to the block you are calling, which then returns control. So it's "yield" as in a multiprocessing context. I would guess that is how CLU came to use that term, and I guess Ruby got it from CLU. (I'm only going by hearsay.) Hal