* Jim Weirich <jim@weirichhouse.org> [2005-05-12 23:32:52 +0900]:
I use to pitch my tent in the one line => braces camp. But every time my
one liner tent grew to more than one line, they made me repitch my tent
using begin/end tent stakes. That's when I moved to the return value =>
brace camp.
I came from the C camp, where everything looked like {}.
Since my editor supported matching these curly things,
I (usually) pitch camp at { || ... }.
Welcome, fellow. Have some marshallows.
My rule of thumb is like this: I use {} constantly, except for
rakefile rules and other similar domain specific/configuration
languages.
Usually, this results in a nice mix of `}' and `end' closing their
beginnings, and makes finding the matching beginning easier. YMMV.
BTW, I do regularly hike up to the ternary operator camp as well, so I'll
see you there.
I too like this camp since it is a short hike, but since I
don't like strenuous activitiy, I never nest them.
Welcome, fellow...
Then, I'm often in the camp of inline-case users... how about you?
I know, it's not 100% reliable... but it suggests that, at least
roughly, 3% of 'do' blocks end on the same line, while 62% of {}
blocks end on the same line. So this "odd" behavior is actually
pretty canonical
Hmmm ... More statistics, same code base, same disclaimers.
* Christian Neukirchen <chneukirchen@gmail.com> [2005-05-13 03:03:54 +0900]:
Then, I'm often in the camp of inline-case users... how about you?
The camp I belong to here is what yields the best readability.
For example:
# for returning short, simple expressions
fred =
case x
when 'y' then true
when 'n' then false
else raise
end
# for doing multiple actions - usually no return value
case x
when 'y'
do_long_compute_1
do_long_compute_2
when 'b'
do_long_compute_3
do_long_compute_4
else
raise
end
···
--
Jim Freeze
Ruby: I can explain it to ya but I can't understand it fer ya.
> I know it's way too late for the Ruby 1.X series, but I'd like to
see a
> change for Ruby 2 that reserved braces for hashes and blocks had to
have
> do/end.
You'll have to fight it out with the ones who wanted braces for block
literals and hashes to be something else
/me fumbles around trying to find his personal sword to join the fray.
I would agree that the duality of {} vs do/end is a bit odd and sort of
unlike Ruby. (I could stretch and say "You can have arbitrary
delimiters for all sorts of literals, so...blocks are sort of like
that" but it would be a stretch.)
I'd far, far prefer {} for blocks than only do/end. One of the greatest
strengths of Ruby IMO is simple iterators using closures. You can do
the exact same thing in Javascript, but it looks like this:
myArray.each( function( obj ){
alert( obj );
} );
Obviously that's TERRIBLE. And the reason it's terrible is the large
amount of crap you have to type to express a simple concept.
The degree to which blocks become harder/longer to type is the degree
to which Ruby loses some of its shine, IMO.
Tangentially, inject uses the first value of the enumerable as the seed
if you don't supply one (the joys of dynamic typing!), so you can simply
say (1..100).inject {|r,v| r*v}
It looks like you can only claim to be mainstream if you use *both*
styles Or am I reasoning wrongly?
Since value returning blocks tend to be shorter than side-effecting
blocks[1], I'm not surprised that there is a correlation between the two
styles.
I guess do/end vs {} is Ruby's version of the "One True Brace Style"
argument.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Tangentially, inject uses the first value of the enumerable as the
seed if you don't supply one (the joys of dynamic typing!), so you
can simply say (1..100).inject {|r,v| r*v}
This might or might not work, depending on the requirements of the
surrounding code:
.inject(1){|a,b| a*b}
=> 1
.inject{|a,b| a*b}
=> nil
.inject(0){|a,b| a+b}
=> 0
.inject{|a,b| a+b}
=> nil
:-))
If you want to detect the case where there are no elements go without the
argument. If you don't care and just want the sum / product provide an
argument (the neutral element of the operation).
How is that one an array? Oh, is it an array containing 'true'?
I've never been super fond of '=>' as a syntax for creating hashes, but I
can accept it. The point I'm trying to make is that currently it's easy
to visually confuse a block and a hash. I'd prefer if array, block and
hash were all visually distinct, but I think it's much less dangerous to
have arrays and hashes look similar because they are similar creatures.
Ben
···
On Thursday 12 May 2005 15:22, Joel VanderWerf wrote:
How is that one an array? Oh, is it an array containing 'true'?
irb(main):001:0> ["a" <= "b"]
=> [true]
I've never been super fond of '=>' as a syntax for creating hashes, but I can accept it. The point I'm trying to make is that currently it's easy to visually confuse a block and a hash. I'd prefer if array, block and hash were all visually distinct, but I think it's much less dangerous to have arrays and hashes look similar because they are similar creatures.
OTOH, hashes and arrays tend to be used in the same kinds of places, and blocks tend to be in different places, so context helps us distinguish hashes from blocks in the current syntax.
···
On Thursday 12 May 2005 15:22, Joel VanderWerf wrote:
I've never been super fond of '=>' as a syntax for creating hashes, but I can accept it. The point I'm trying to make is that currently it's easy to visually confuse a block and a hash. I'd prefer if array, block and hash were all visually distinct, but I think it's much less dangerous to have arrays and hashes look similar because they are similar creatures.
OTOH, hashes and arrays tend to be used in the same kinds of places, and blocks tend to be in different places, so context helps us distinguish hashes from blocks in the current syntax.
Yes, and another thing that's getting lost in the mix here is the fact
that {} and do/end are not the same as each other. They have
different precedence. It's not just a whimsical TMTOWTDI thing.
I've never been super fond of '=>' as a syntax for creating hashes,
but I can accept it. The point I'm trying to make is that
currently it's easy to visually confuse a block and a hash. I'd
prefer if array, block and hash were all visually distinct, but I
think it's much less dangerous to have arrays and hashes look
similar because they are similar creatures.
OTOH, hashes and arrays tend to be used in the same kinds of places,
and blocks tend to be in different places, so context helps us
distinguish hashes from blocks in the current syntax.
Yes, and another thing that's getting lost in the mix here is the fact
that {} and do/end are not the same as each other. They have
different precedence. It's not just a whimsical TMTOWTDI thing.
I'm glad someone finally mentioned this. I was about to write the same...
Have some marshallows.