From: dblack@... Date: 2003-04-26T21:03:28+09:00 Subject: Re: block.call vs. yield Hi -- On Sat, 26 Apr 2003, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: block.call vs. yield" > on 03/04/25, dblack@superlink.net writes: > > |Language comment: > | > |'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? > > Could you restate your statement? The follow-ups captured most of my meaning, but I'll follow up myself anyway. In a 'yield', the block is being yielded *to* -- it is not, itself, yielding control. Therefore, what you'd really need, to describe a yield in terms of the block as a receiver, would be something like: blk.be_yielded_to which I'm not advocating, of course; it's just that blk.yield suggests that the block is performing an action described as 'yield'ing, which I don't think it is. Also, the use of 'yield' as shorthand for 'call with certain semantics' (if I'm understanding that correctly) seems very obscure to me. This would be very hard to explain to someone learning Ruby ("The block isn't actually yielding control; the method is called 'yield' because elsewhere in the language there's something called 'yield' that has the same calling semantics...."). In that regard, to me it has a similar feel to: proc { |a,*b| ... } .def # call proc using arg semantics # of a method definition David -- David Alan Black home: dblack@superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav