From: brian ford Date: 2009-08-24T13:03:53+09:00 Subject: [ruby-core:25068] Re: Proposal: Simpler block format Hi, On Sun, Aug 23, 2009 at 4:53 PM, David A. Black wrote: > Hi -- > > On Mon, 24 Aug 2009, Yehuda Katz wrote: >> >> The compelling this for me is that it makes methods that take multiple >> blocks easier for programmer to read. For programmer, one big confusion in >> Ruby is difference between proc, block, lambda and method. Unifying syntax >> for block and proc shows that they are really just same thing, with proc >> passed as parameter and block passed as special parameter. > > I have to admit that this strikes me as a solution in search of a > problem, in that I've never had any trouble reading methods that take > Proc objects as arguments. Also, I think that with the unification of > block and method parameter semantics, things are getting a lot less > confusing as to the differences among them. > > I don't consider a block to be the same thing as a proc, nor do I > consider it a method argument. The block is part of the method-call > syntax; in itself, it isn't an object (just as the argument list is > not, in itself, an object). > >> Then whenever programmer sees { something } they know it is "proc" with >> lexical scope, and whenever programmer sees ->{ something } they know it >> is >> "lambda" with function scope. > > One danger of { something } being a proc is that it does away with the > error message for odd-numbered hashes -- an edge case, admittedly, but > still. > >> I would even be in favor of def { } as lambda syntax, which would make >> clear >> to programmer that this block behaves just like normal method. Then we >> have >> just two things: def for method-scope (def something() end and def { }) >> and >> bare { } for block scope. > > Dave Thomas brought up the def { } thing at RubyConf 2005, I believe, > and got a big round of applause :-) It's definitely way better than > ->() (which I still sort of hope will disappear, though my hope is > fading). I am desperately hoping for a miracle, that ->() will be removed. Could we add def {} and see by usage which prevails? Or take a world-wide vote (perhaps weighted by number of lines of Ruby code written by the voter)? Alas, if ->() stays, we will at least have an easy pick for the ugliest bit of Ruby syntax. BTW, could someone share code that effectively uses something like: call_method -> { proc_1 }, -> { proc_2 }, -> { proc_3 } Cheers, Brian > > > David > > -- > David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com > Q: What's the best way to get a really solid knowledge of Ruby? > A: Come to our Ruby training in Edison, New Jersey, September 14-17! > � Instructors: David A. Black and Erik Kastner > � More info and registration: http://rubyurl.com/vmzN > >