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!