On 2/2/06, James Edward G. II [email protected] wrote:
For what it’s worth, I also strongly dislike it.
Amen brother.
I don’t think Ruby ever needs to be ashamed of being Ruby.
+1;;
Yukihiro M. wrote:
We are experimenting double semicolons as well as "end"s, so that you
class FooBut I’m still not sure if it’s good enough to be remained in 2.0.
No, don’t worry, we are NOT going to remove "end"s from the language;
double semicolons are just alternative.
I opt against. Reasons:
-
difficult to read especially with multiple “end”'s (as others have
pointed out already) -
I doesn’t feel right (aesthetically) to end something started with a
word (“def”, “begin” or “do”) with punctuation -
It could break existing code in very rare circumstances, i.e. if
someone used ;;;;;;;;;;;;;; as a visual boundary.
Kind regards
robert- On Feb 3 13:07, MenTaLguY ([email protected]) wrote:
For what it’s worth, I also strongly dislike it. It was one of my
least favorite features of OCaml’s syntax.But here, the biggest problem is that (relative to other block endings
in pretty much any language I can think of), it’s much harder to
visually count ;;s if they are squashed together as in your example.I think this is largely because there aren’t any visual cues to the
boundary between tokens. The gap between two ;s within the same ;; and
the gap between two ;s in adjacent ;; aren’t visually distinguishable.
I was going to write my own post, but it seems MenTaLguY did it for me!
I am in total agreement; semicolons are an ugly way to end sections.
Curly braces I have a much easier time with.
Tom
On 2/3/06, Thomas K. [email protected] wrote:
the gap between two ;s in adjacent ;; aren’t visually distinguishable.
I was going to write my own post, but it seems MenTaLguY did it for me!
I am in total agreement; semicolons are an ugly way to end sections.
Curly braces I have a much easier time with.
I’m not a fan of the curly braces, but if we do end up using them, I
hope we don’t allow this.
def some_method(args)
some code
}
If we’re going to use them, I think they need to be matched, so a {
should appear at the end of the method argument list.
hi,
if we do end up using them
in this discussion, a sentence with the words ‘do’ and ‘end’ is hard to
read
properly 
but seriously…
If we’re going to use them, I think they need to be matched, so a {
should appear at the end of the method argument list.
i think this is a bad idea, i really prefer keywords over punctuation,
because it’s easy to find a spelling error in a keyword (especially if
your
editor highlights them) but i often find i used one brace and one
bracket,
which is easily overlooked and easily done, as the button are close to
eachother on the keyboard.
and it looks too much like Java to me
greetings, Dirk
- On Feb 3 23:14, Mark V. ([email protected]) wrote:
I’m not a fan of the curly braces, but if we do end up using them, I
hope we don’t allow this.def some_method(args)
some code
}
If we’re going to use them, I think they need to be matched, so a {
should appear at the end of the method argument list.
Oh, I definitely agree here - I should have clarified. I enjoy
matched
curly braces 
In most cases, I prefer curly braces for blocks rather
than “do … end”.
However, I don’t think they’re necessary here - “def method() … end”
works well and looks good. It’s balanced.
Tom
Rubyist wrote:
[. . .]
I haven’t liked them. But curly braces may me quite better.
I’d vote for curly braces, if it’s possible at all. (Curly braces are
already used for blocks, so I’m not sure it’s possible/feasible.)
In fact, “do”, “then”, “end”, etc. make one-liners harder to read
and, as a result, make them less valuable. Compare,
for example,
if cond then meth this; func that end #(1)
with
if (cond) {meth this; func that} #(2)
The second is easier to grasp at a glance. Why?
Because “names” are written in words and grammatical
constructions are written in symbols (except for “if”).
Code (1) is harder to read because everything is a word.
In any case, however, I’m quite happy with Ruby. This issue
is very minor at best. All I’m saying is, if possible, I prefer
the style of code (2).
Regards,
Ryo
Even if “end if” is no longer feasible to parse because of the if
modifier there is still the possibility to have optional “end def” and
“end class” instead of just “end”. It could make finding the place
where an end is missing much easier.Michal
(0…10).each do |i|
Do something with i
end what?
I agree with you mostly on this kind of option, since I always add
comments after every ‘end’ of a deep embedded structure to make the
logic more readable.
Sky Y. wrote:
Do something with i
end what?
end do
- On Feb 4 4:28, Doug H ([email protected]) wrote:
(0…10).each do |i|
Do something with i
end what?
end do
My first reaction was “end each”… After all, “do” and “end” are just
the keywords. "end " should refer to the actual construct
you’re ending, not just a keyword.
Either way, I think it’s ugly 
Tom
On 2/2/06, Hal F. [email protected] wrote:
I’ve implemented this as well in a separate project.
Not a bad idea in itself. In fact, I think that really old Ruby
versions (prior to my learning it with 1.4) did something like
that. When modifiers were introduced (x if y, x while y, etc.)
parsing became difficult and they were dropped. I think that’s
the case.
Even if “end if” is no longer feasible to parse because of the if
modifier there is still the possibility to have optional “end def” and
“end class” instead of just “end”. It could make finding the place
where an end is missing much easier.
Michal
Thomas K. wrote:
- On Feb 4 4:28, Doug H ([email protected]) wrote:
(0…10).each do |i|
Do something with i
end what?
end do
My first reaction was “end each”… After all, “do” and “end” are just
the keywords. "end " should refer to the actual construct
you’re ending, not just a keyword.
You’re ending a closure block, which starts with “do”.
On 2/3/06, Doug H [email protected] wrote:
(0…10).each do |i|
Do something with i
end what?
end do
I’ve always just done this:
def blah(var)
if something
case var
when ‘x’
foo
when ‘y’
bar
end#case
end#if
end#blah
2006/2/3, Wilson B. [email protected]:
end#case
end#if
end#blah
best solution i’ve seen so far! sticks thumb up i think i’ll start
using
that too 
I may take back the previous agreement on the “end option”. Since
there’s a space between “end” and the “option” (otherwise we have to
introduce tons of new key words), it’s hard to parse. For example, how
can the interpreter know the “while” in “end while” is not a key word
to begin a while loop? For the iteration example I asked, the actually
comment I put in code is:
(0…10).each do |i|
Do something with i
end # Next i
More readable?
On 3 Feb 2006, at 21:18, Doug H wrote:
the keywords. "end " should refer to the actual construct
you’re ending, not just a keyword.You’re ending a closure block, which starts with “do”.
I’ve been following this quietly. Just thought I’d drop in a thought
here. Quietly.
I don’t get why you would want that “do” there. It would be a little
like finishing every paragraph with the statement “I have now
finished this paragraph”. I have now finished this paragraph.
To me, I’m able to track the “end” and see what it matches to.
Earlier in this thread somebody said if there were more than 3 or 4
end statements in a row, your code is written incorrectly, and they
probably have a good point. I really don’t see what you’re trying to
do with this - I’d just think we had ended one block, of type unknown
or unimportant, and now we were starting another “do” block. I have
now finished this paragraph.
As for punctuation, well, I suspect the people who think stray ‘}’
and ‘;’ or ‘;;’ tags everywhere have come here from Perl: a language
whose sole objective is to find a use for every single symbol on the
keyboard. It is so un-Ruby when I first saw those mails I wanted to
make a little pile of sick next to me in disgust. I didn’t, but I
wanted to. A little bit, at least. I have now finished this paragraph.
Keep Ruby where it is, and if you somehow end up writing code that is
hard to read, you’ve learnt Ruby wrong and you need to re-write your
code, simple as that. My Mum says re-factoring makes you strong and
able to see in the dark, so make sure you do it regularly. I have now
finished this paragraph.
My 2p. I have now finished this paragraph. I have now finished this e-
mail.
(apart from the sig)
Hi,
I’m not the most experienced Ruby user, but for what it’s worth one of
the
reasons I chose to program in Ruby is because the language looked, to
me, so
damn nice. I’m an artist who works as a programmer, so flaky reasons
like
the aesthetics of the code were very important to me in deciding to take
Ruby on.
I don’t really like the idea of ;; because to me it breaks the beauty of
Ruby code. But I do like the idea of have symbols replace an ‘end’. My
take
on a nicer symbol to use would be ‘<’, it’s like pointing back to the
margin
saying ‘go home now’. Except, any multiple symbol would, I think, not
really
help to clarify the code, and would instead just be quicker to type than
‘end’. How about having one symbol, which basically would end all nested
functions and conditionals, except not close the class.
So working with Matz’s example, it would look like this:
class Foo
def bar(a)
p a
<
end
Or, with more nesting
class Foo
def bar(a)
if (a)
p a
<
end
So, without a class, code could look like this:
if (a)
if (b)
if (c)
if (d)
p e
<
?
Luke
“Yukihiro M.” [email protected] wrote in message
news:[email protected]…
Hi,
In message "Re: Indentation vs. “end"s”
on Thu, 2 Feb 2006 06:37:02 +0900, “Rubyist”
[email protected] writes:
Austin Z. ha scritto:
What do you think about those "end"s? Do you REALLY like them?
Will Ruby-2 offer an alternative? Well, maybe not “indentation” but
will another solution be available?I hope that the mistake that Python makes isn’t repeated in Ruby 2.0.
I prefer explicit – and more flexible – than implicit and
inflexible.
are you citing line 2 of “the zen of python”[1] consciously?
In other words, I really do like the ends.
I always have the feeling that there could be something better than
ends, but untile I find it I’m happy with them.
What do you think about those "end"s? Do you REALLY like them?
Will Ruby-2 offer an alternative? Well, maybe not “indentation” but
will another solution be available?
I really like “end” IF there is an autocomplete feature in the editor.
If
not, well… But the main point is that, it makes the code clearer, and
that’s why I like it. (again if the editor autocompletes ‘end’ for me
)
DÅ?a Sobota 04 Február 2006 10:53 gabriele renzi napÃsal:
Austin Z. ha scritto:
I prefer explicit – and more flexible – than implicit and
inflexible.are you citing line 2 of “the zen of python” consciously?
The irony is UNBEARABLE, I tell ya…
To make this less complete spam, I state I don’t like curly braces. I
blame
the horrors of learning C at college, the horrors of coding JavaScript
at
school, and this godawful cheapo plastic taiwanese keyboard with a
German
layout that makes typing them a horrible pinky-strain.
That said, I can somehow understand, if not actively appreciate Ruby
having
optional C-like features for the sake of C-likeness. The forces of
marketing
in the programming language market are brutal and unyielding, the fact
people
are willing to accept, nay, like C# with its deluge of keywords, half of
which mostly serve for the compiler only to slap you for not using them
when
appropriate. (Why the hell can’t I use ``this’’ to reference static
members
in a static context?! bangs head against wall)
David V.
Slashdot score me and have your goldfish die