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?
We are experimenting double semicolons as well as "end"s, so that you
can type
class Foo
def bar(a)
p a
;;
;;
instead of
class Foo
def bar(a)
p a
end
end
Or you can even type
class Foo
def bar(a)
p a;;;;
But 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
···
In message "Re: Indentation vs. "end"s" > on Thu, 2 Feb 2006 06:37:02 +0900, "Rubyist" > <nuby.ruby.programmer@gmail.com> writes:
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 Matsumoto" <matz@ruby-lang.org> wrote in message
news:1138877284.580712.22693.nullmailer@x31.priv.netlab.jp...
···
Hi,
In message "Re: Indentation vs. "end"s" > on Thu, 2 Feb 2006 06:37:02 +0900, "Rubyist" <nuby.ruby.programmer@gmail.com> writes:
>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?
We are experimenting double semicolons as well as "end"s, so that you
can type
class Foo
def bar(a)
p a
;;
;;
instead of
class Foo
def bar(a)
p a
end
end
Or you can even type
class Foo
def bar(a)
p a;;;;
But 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.
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.
Yes I really like the end statements, and they make it easier for
beginners. It's possible to support both indenting and end statements
(i.e. support one mode or the other), and you don't need python's
redundant and unnecessary colons. I implemented this myself in a
parser. I don't think it is appropriate for ruby, however.
What would be even better would be to allow optional labels after end
statements, such as "end class", "end def", so the parser can catch
more errors.
I've implemented this as well in a separate project.
Instead of voting for multiple "end xxx", I would like to suggest that
more pairs/keyword than "do ... end" and "{ .. }" can be used to define
a block.
For examples:
begin ... end
is ... end
then ... end
Because sometimes, the correct word is not "do". For examples to define
mapping I'd like to do
Brain.learn :cooking is
...
end
rather having "do" there.
It also simplify many semantic in Ruby for example. defining
class/method could be viewed as a method that takes a block. But "do"
wouldn't make sense there, but:
class Person is #<<< just a method taking a block
def say(message) is #<<< Don't know :S
...
end
end
It may make Ruby code reflect more closely to what I am thinking in
word.
Or how 'bout "if - fi" and "until - done" and "for - done"...
nah. As much as the Bourne shell has a few constructs that
seem to meet your criteria, I don't think it's the answer.
I have to say, as much as I like the idea of significant
whitespace for *certain* things (preservation of vertical
space; force new programmers to indent), I just don't think it's
the right solution here, either.
Besides, Python has no solution for *which* scope is ended when
code is reverse indented. It's clean, but not descriptive.
I agree that Ruby's explicit "end"s make it nicer for use in
erb. And at least this way you can, for your posterity's sake,
do:
stuff.each do |thing|
if thing.instance_of?(other_thing)
thing.action()
end # if
end # each stuff
Cheers,
Tim Hammerquist
···
Rubyist <nuby.ruby.programmer@gmail.com> wrote:
<doug00@gmail.com> wrote:
> What would be even better would be to allow optional labels
> after end statements, such as "end class", "end def", so the
> parser can catch more errors.
That sound like a good idea. But what about "if", "when",
"for", "until" etc?
Hmm...
"endif", "end when", "end for", "end until", "end class", "enddef",...
i like the "end"s, it reminds me of the old days when i programmed my Texas
Instruments calculator and always forgot an "end" somewhere
···
2006/2/1, Phil Tomson <ptkwt@aracnet.com>:
In article <nUfDf.49093$Kp.5722@southeast.rr.com>,
Jeffrey Schwab <jeff@schwabcenter.com> wrote:
>Rubyist wrote:
>> Hi,
>>
>> I *REALLY* love Ruby very much. But I always find those "end"s somewhat
>> ugly ( thousands of excuses to Matz ). I sometimes feel myself wishing
>> that Ruby use indentation (as Python does) instead of "end"s.
>>
>> Today, I have seen a post in:
>>
>> Ruby, PHP and a Conference
>>
>>
>> As far as I know, Bruce Eckel is a competent programmer and when I saw
>> that he was agree with me, I surprised.
>>
>> 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 like having something to search for in my editor. Explicit
>block-ending tokens also help when I am skimming code to review its
>structure.
And having 'end' sure makes things like ERB easier (possible) to
implement.
I'm not particularly fond of IF ... ENDIF constructs, but one can simulate this:
def foo
...
end # def foo
I don't do it, though. Vim does a damn fine job of folding things for me.
-austin
···
On 01/02/06, Rubyist <nuby.ruby.programmer@gmail.com> wrote:
>> What would be even better would be to allow optional labels after end
>> statements, such as "end class", "end def", so the parser can catch
>> more errors.
That sound like a good idea. But what about "if", "when", "for",
"until" etc?
Hmm...
"endif", "end when", "end for", "end until", "end class", "enddef",...
Umh! A never "ended" nightmare.
"Rubyist" <nuby.ruby.programmer@gmail.com> wrote in message
What do you think about those "end"s? Do you *REALLY* like them?
I typically find I'm doing something wrong if I have five ends in a row. Too much complexity in one method. Three is usually my max, but I don't make a rule of it, it just happens.
I think we can learn a lot from programming languages and Python.
First off, we should be writing in a fixed space font so we
can take visual cues from spacing more easily.
Next, why do we need periods at the end of a sentence
when we know that two spaces after a word mean
that the previous sentence just ended Doesn't
that make sense And do we really need caps at
the beginning of a sentence we know all sentences
are capitalized and we have just defined that
two spaces before a word means that it is at the
beginning of a sentence next we should look at
spelling double consonants don't realy add to
the meaning so begining now we spel words by
droping repeated consonants just look at al
these great benefits we can learn from python
self.we self.just self.need self.to self.learn
self.to self.ignore self.certain self.aspects
self.that self.may self.cary self.over
···
On Feb 1, 2006, at 3:38 PM, Rubyist wrote:
I have looked at some of my and other people's Ruby code and
often been tempted to select those last 5
'ends' and hit the delete button. : )
Thank God! I am not alone on the earth! ;-D
Man, you've made me so laughed! Hahaha!
In message "Re: Indentation vs. "end"s" on Thu, 2 Feb 2006 15:07:27 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:
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.
Very old versions of Ruby, before Wed August 24 1994, according to the
ancient record of history.
On 2/3/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
It sounds to me like it'll make reading ruby libraries / code a bit
more difficult since both can exist. Is it worth that price? Am I
missing something?
No. The purpose of this experiment is hearing other opinions. So
yours is quite worthwhile.
We are experimenting double semicolons as well as "end"s,
...
But 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.
why? quite seriously, and quite naively, I don't understand the benefit.
Maybe it's just me, but the
class Foo
def bar(a)
p a;;;;
looks really different from the (current) standard
class Foo
def bar(a)
p a
end
end
It sounds to me like it'll make reading ruby libraries / code a bit
more difficult since both can exist. Is it worth that price? Am I
missing something?
;; is used to end case statements in some popular Unix shells. I have to admit that ;;;; still looks a bit odd to me.
Thank you, Matz.
···
On 2/2/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
The semicolons, imho, aren't visible enough to the (my?) eye. I still
believe that the curly brace to END is a decent option as it already
is familiar to many others
I agree. Although using semicolons sounded a good idea for me, when I
saw:
def foo()
blah blah
blah blah
if blah blah
;;;;
I haven't liked them. But curly braces may me quite better. Yes... I
think it's worth to try without totally removing the "end"s. Just an
optional implementation. I am already *very happy* with Ruby's many
optional solutions. One may use or not "then"s, one may write a single
line conditional without using "end"s etc.
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
···
On 2/2/06, Hal Fulton <hal9000@hypermetrics.com> wrote:
doug00@gmail.com wrote:
> Yes I really like the end statements, and they make it easier for
> beginners. It's possible to support both indenting and end statements
> (i.e. support one mode or the other), and you don't need python's
> redundant and unnecessary colons. I implemented this myself in a
> parser. I don't think it is appropriate for ruby, however.
>
> What would be even better would be to allow optional labels after end
> statements, such as "end class", "end def", so the parser can catch
> more errors.
> 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.
Me too. I always say that the Ruby all control
structures always ends on the end. It's easier and
simpler. If-(endif-fi-etc) makes some confusion when
you work with a couple of languages. Ends are cool.
And, talking about indentation, with we work with tab
we'll have another dilema: tabs or spaces, as Python.
>>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 Ziegler 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 Vallner
Slashdot score me and have your goldfish die
Intriguing idea, but completely ad-hoc, and potentially confusing and
unreadable. Especially if someone were to apply it with the "Few small
classes per method" style of programming, or any similar meta contexts. What
exactly would the ``<'' close then? The innermost or the outermost class?
What about a module used as a namespace containing several spaces classes in
a single source file?
A magic "end almost everything for given values of almost everything" would be
just repeating the constant lookup issue all over again. Not necessarily a
problem to bite you in the majority of cases, but another bit of syntax most
people can't really remember how it really works.
I might also be horribly, horribly wrong. In that case, ignore me as usual.
David Vallner
Dňa Sobota 04 Február 2006 08:13 Luke Duncalfe napísal:
···
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 Matsumoto" <matz@ruby-lang.org> wrote in message
news:1138877284.580712.22693.nullmailer@x31.priv.netlab.jp...
doug00@gmail.com wrote:
> Yes I really like the end statements, and they make it easier for
> beginners. It's possible to support both indenting and end statements
> (i.e. support one mode or the other), and you don't need python's
> redundant and unnecessary colons. I implemented this myself in a
> parser. I don't think it is appropriate for ruby, however.
>
> What would be even better would be to allow optional labels after end
> statements, such as "end class", "end def", so the parser can catch
> more errors.
> I've implemented this as well in a separate project.
Instead of voting for multiple "end xxx", I would like to suggest that
more pairs/keyword than "do ... end" and "{ .. }" can be used to define
a block.
For examples:
begin ... end
is ... end
then ... end
Because sometimes, the correct word is not "do". For examples to define
mapping I'd like to do
Brain.learn :cooking is
...
end
rather having "do" there.
It also simplify many semantic in Ruby for example. defining
class/method could be viewed as a method that takes a block. But "do"
wouldn't make sense there, but:
class Person is #<<< just a method taking a block
def say(message) is #<<< Don't know :S
...
end
end
It may make Ruby code reflect more closely to what I am thinking in
word.
To extends it further, may be a syntax for a method to specify what
word they want to use instead of "do". It must be possible to still use
"{}" or "do/end", just that another word can also be used instead.
For example of where "do" isn't the right word (at least for me), look
at Markably and Ezra's Where Plugin.
