Hi --

On Sun, 25 May 2008, Eric Mahurin wrote:

> On Sun, May 25, 2008 at 6:46 AM, David A. Black <dblack / rubypal.com> wrote:
>
>> Hi --
>>
>> On Sun, 25 May 2008, Phlip wrote:
>>
>>   assert_yin_yang proc{ q +=  0 }, 'it broke!',
>>>>>                 proc{ q == 42 }
>>>>>
>>>>> That sorta obviates my standard advertizing jingle - more assert bang
>>>>> for less coding buck! 'proc' ain't DRY there...
>>>>>
>>>>
>>>> I don't think I'd describe those two 'proc's as a case of repeating
>>>> yourself, since each of them is serving the minimal purpose that
>>>> 'proc' can serve. Or, to put it another way, proc { q == 42 } is in no
>>>> way a repetition of proc { q += 0 }.
>>>>
>>>
>>> You are correct that the most important aspect of the DRY rule is
>>> behavior, so to your trained Ruby eye the payload - q == 42 and q += 0 - are
>>> indeed distinct. In this way, 'proc' is structure, which is harder and less
>>> useful to DRY up.
>>>
>>> Yet if I'm trying to sweeten the syntactic sugar of my assertion, the
>>> 'proc' simply adds excess verbiage that adds nothing to readability. So the
>>> ->
>>>
>>
>> My view is that it isn't excess, any more than in this case:
>>
>>  class A
>>    ...
>>  end
>>
>>  class B
>>    ...
>>  end
>>
>> the second appearance of 'class' is excess.
>>
>>  operator (or whatever it arrives as) will indeed be much safer than _{}!
>>>
>>
>> I'm still hoping it might arrive as "lambda" :-)
>>
>
> Take a look at the fully implemented 2 patches I posted yesterday.  Here's
> what they do:
>
> "block w/ default args": allows block arguments to have defaults.  I
> resolved | ambiguity by only allowing a <primary> for default values.  This
> allows the normal "lambda" (not a keyword) to do the same thing as -> in a
> syntax we already know - block.
>
> "lambda w/ normal block syntax": automatically creates a lambda when { |...|
> ... } or do ... end are used in a <primary>.  I require the |...| to be used
> for {} to disambiguate with a Hash.  The are equivalent to preceding them
> "lambda".
>
> These two patches may be independently applied.  They should cause any
> compatibility problems.

I did see them, and I think they're very cool. I definitely root for
the default argument behavior to be folded into lambda, rather than
spun off into ->(){}. I admit I'm not a fan of the empty ||, though,
but I'm starting to think they'd be better than the arrow syntax.


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!