On Sun, Aug 23, 2009 at 9:03 PM, brian ford<brixen / gmail.com> wrote:
> Hi,
>
> On Sun, Aug 23, 2009 at 4:53 PM, David A. Black<dblack / rubypal.com> 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 syn=
tax
>>> for block and proc shows that they are really just same thing, with pro=
c
>>> 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 i=
t
>>> 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:
>
> =A0call_method -> { proc_1 },
> =A0 =A0 =A0 =A0 =A0 =A0 -> { proc_2 },
> =A0 =A0 =A0 =A0 =A0 =A0 -> { proc_3 }

It's nice for declarative style:

Sampler.new do
  sample 'Memory/Resident',
    available: -> { File.exist? "/proc/#{$$}/status" }
    measure: -> { $1.to_i if File.read("/proc/#{$$}/status") =3D~ /RSS:\s*(=
\d+)/ )

  sample 'Objects/Live',
    available: -> { ObjectSpace.respond_to? :live_objects },
    measure: -> { ObjectSpace.live_objects }
end

jeremy