From: Daniel Brockman <daniel@...>
Date: 2005-07-01T04:11:55+09:00
Subject: Re: iterators and block arguments

Zach Dennis <zdennis@mktec.com> writes:

> Daniel Brockman wrote:
>
>>     ipv4s.collect! { IPv4Address[@] }
>>     publics = ipv4s.select { @.public? }
>>     privates = ipv4s.select { @.private? }
>>     loopbacks = ipv4s.select { @.loopback? }
>
> I disagree. I think this is absolutely horrid looking.

How so?  Because of the choice of character?  A more mnemonic but less
compatible syntax would be to use an underscore instead of a snail.

    loopbacks = ipv4s.select { _.loopback? }

This is mnemonic because `_' suggests ``fill in the blank,'' but less
compatible because it is currently a valid name.  Why the lucky stiff
actually uses it, but I doubt if he ever used it inside a block.

Another notation that I like is `<>' from SRFI 26.
(See <http://srfi.schemers.org/srfi-26/srfi-26.html>.)

    loopbacks = ipv4s.select { <>.loopback? }

The `<>' is pronounced ``slot''.  It also happens to look like a gem.
(The semantics are not exactly those of SRFI 26, but close enough.)

I may actually prefer the underscore; I'm not really sure.  I know I
prefer `<>' over `@', and maybe I shouldn't have mentioned the latter.

What do other people think?

> And I think that
>
> ipv4s.collect! { |ip| IPv4Address[x] }
>
> is better.

No comment.

> And even if you don't think it adds to readability for single value
> blocks I like it for things like...
>
> server.process( connection ) do |msg, msg_type, socket|
> 	# do connection procesing here...
> end

Allow me to raise my voice.  OF COURSE IT ADDS READABILITY TO LONG
BLOCKS WITH THREE PARAMETERS.  I'm only talking about short blocks
with one parameter.  Did you seriously think I was suggesting we
deprecate formal parameters altogether?

-- 
Daniel Brockman <daniel@brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.