Indentation vs. "end"s
Rubyist
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:
http://www.artima.com/weblogs/viewpost.jsp?thread=146091
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?
Luke Duncalfe
"Rubyist" <nuby.ruby....@gmail.com> wrote in message
news:1138571607....@z14g2000cwz.googlegroups.com...
I've got to declare that I also like the idea of dropping the ends a la
Python, although if the effect of that is that your whitespace becomes
strict I'm not sure which way is better. 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. : )
Luke
Jeffrey Schwab
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.
dou...@gmail.com
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.
Phil Tomson
And having 'end' sure makes things like ERB easier (possible) to implement.
Phil
Rubyist
>> 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!
Rubyist
>> 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.
Tim Hammerquist
Rubyist <nuby.ruby....@gmail.com> wrote:
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
ngw
> 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?
You're asking for trouble when using something like eruby.
ngw
Gennady Bystritsky
for honorable Bruce Eckel too).
Otherwise it looks like an inviation to a flame.
Gennady.
> -----Original Message-----
> From: Rubyist [mailto:nuby.ruby....@gmail.com]
> Sent: Wednesday, February 01, 2006 13:37
> To: ruby-talk ML
> Subject: Indentation vs. "end"s
>
> 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:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=146091
>
>
> As far as I know, Bruce Eckel is a competent programmer and
> when I saw that he was agree with me, I surprised.
>
Dirk Meijer
Instruments calculator and always forgot an "end" somewhere :P
2006/2/1, Phil Tomson <pt...@aracnet.com>:
Eric Hodel
> "Rubyist" <nuby.ruby....@gmail.com> wrote in message
> news:1138571607....@z14g2000cwz.googlegroups.com...
>> 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've got to declare that I also like the idea of dropping the ends
> a la
> Python, although if the effect of that is that your whitespace becomes
> strict I'm not sure which way is better. 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. : )
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.
--
Eric Hodel - drb...@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant
Robert Klemme
> 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.
> 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 don't even think about them. I just use the language as it is.
robert
--
Have a look: http://www.flickr.com/photos/fussel-foto/
Austin Ziegler
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. In other words, I really *do* like the ends.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Austin Ziegler
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.
gban...@gmail.com
but before I chose Ruby as the definite language I tried writing in as
many other languages as I could, including Python.
I understand the importance of indentation, but forcing it on me was
really painful. I honestly wanted to stab someone every time I got an
error (ruby give me an error too when I missed an end, but it's somehow
different). There is something incredibly soothing about writing
freeform and freestyle code in Ruby which I don't get in Python.
What I'm afraid of now is going to college next year and having to deal
with "stricter" languages.
Good Luck!
Gabriel
PS: Yes, I know writing code cowboy style is bad, but hey, I'm a
newbie. ;)
David Vallner
> 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.
Holy mother of god in the heavens, for the love of all that's good and sacred,
please NO! I've had more than enough XML and VHDL already, thankyouverymuch.
Next thing you see we're coding in palindromes to doublecheck we know what
order we wrote the characters in...
I want to see a single half-serious programmer that actually makes errors
because he can't remember what scope he's in. That's what the indentation
conventions are there anyway. If you keep your code well-structured, It's
impossible to have that cause a show-stopping bug that can survive five
minutes in the codebase.
That said, I prefer indentation as a convention, not as syntax. I made certain
sporadic forays into Python; but I like how Ruby tries to resemble natural
language with the likes of statement modifiers, and do/begin and end for code
blocks. It feels more natural to me to type "end" to end a code block, and I
usually associate the backspace key probably the most commonly used in
editors to unindent code manually with correcting typos - ergo not a natural
component in the flow of typing.
Pretty much my $.02
David Vallner
If I had two cents for everytime I say "Just my two cents"...
gwt...@mac.com
On Feb 1, 2006, at 5:21 PM, Eric Hodel wrote:
> On Feb 1, 2006, at 1:37 PM, Luke Duncalfe wrote:
>> "Rubyist" <nuby.ruby....@gmail.com> wrote in message
>
> row. Too much complexity in one method. Three is usually my max,
> but I don't make a rule of it, it just happens.
+1
Gary Wright
Serdar Kılıç
But how about something like this:
def foo
@var
}
--
Cheers,
Serdar Kilic
http://weblog.kilic.net/
James Britt
> ...
> really painful. I honestly wanted to stab someone every time I got an
> error (ruby give me an error too when I missed an end, but it's somehow
> different). There is something incredibly soothing about writing
> freeform and freestyle code in Ruby which I don't get in Python.
Same here. My editor fills in the 'end' stuff for me, so there is no
extra typing. But I have the freedom to adjust the layout to highlight
sections of code to better express intent.
>
> What I'm afraid of now is going to college next year and having to deal
> with "stricter" languages.
Well, that sinks it: Skip college. Code Ruby.
Actually, experience with a variety of languages is usually a Good
Thing, at least to give some perspective.
--
James Britt
http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
Marc
You have an opener and a closer. Indentation strictness... <shudder>
Jeffrey Schwab
> 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 :P
I loved my TI-82, and I remember how excited I was over my 85. Now that
I'm a grown-up, of course, I have a Voyage 200. :)
Hal Fulton
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.
Hal
Dirk Meijer
i used the ti-83+, and still do (as i'm still in high school) i just don't
program it as much as i used to :P
but anyway, one thing i would like better than the current "end"s, is
wrapping everything in do/end like this:
while condition? do
#action
end
or maybe even:
if condition?
then do
#action
else do
#action
end
greetings, Dirk.
Jim Freeze
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
--
Jim Freeze
Ross Bamford
:))))))))))
"Programming languages and Python". Love it.
--
Ross Bamford - ro...@roscopeco.REMOVE.co.uk
Rubyist
>> problem is gone for you (and
>> for honorable Bruce Eckel too).
>> Otherwise it looks like an inviation to a flame.
Is this a "solution"? Are your "solutions" always like this?
"Love or get away".
Hmm... Quite impressive. You can solve every problem with this
approach. I will try it in a spare time.
Fritz Heinrichmeyer
> 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.
if a text is accidentally reformatted (alt-q in emacs, it seems to me
ruby users are more often vim users, at least on this list) semantic is
destroyed, as in python. This is not the case with i.e. javascript or perl.
Maybe ruby as "javascript on steroids" would have even more success.
Blocks could be written with do
container.each do(i,j) { /* like |i,j| */ ..... }
--
Mit freundlichen Grüßen
Fritz Heinrichmeyer FernUniversität, LG ES, 58084 Hagen (Germany)
tel:+49 2331/987-1166 fax:987-355
James Edward Gray II
<dies laughing>
James Edward Gray II
Luc Heinrich
> <dies laughing>
Erm, you probably mean dies.__laughing__(), right ? :>
--
Luc Heinrich - l...@honk-honk.com - http://www.honk-honk.com
Michael Sullivan
Berger, Daniel
> From: Michael Sullivan [mailto:unix...@mac.com]
> Sent: Thursday, February 02, 2006 11:16 AM
> To: ruby-talk ML
> Subject: Re: Indentation vs. "end"s
>
>
> Somehow my first message got swallowed up...
And here I thought you were being ironicle. ;)
Dan
Michael Sullivan
it...
Mike (who'll now go back to lurking...)
Jeff Barczewski
Meino Christian Cramer
Subject: Re: Indentation vs. "end"s
> I like Ruby just the way it is.
Ruby is Ruby not a copy of others.
By the way: Transmitting Python scripts via Web pages or such alike
and being urged to cute'n'paste them into an ascii editor (since
otherwise we git a "Save As" html code ... not ascii) is really
pain since the syntax get burried under "To be space or not to be space"...
("Space wars II...The return of the TAB" or something like that...)
The "End"s are makeing Ruby bullet proof concerning alternate
transmission ways.....may be solid enough to be sent as morse code :)
I like ruby due to the fact it is Ruby !
My two cents only....
mcc
Martin DeMello
Do you dislike writing or reading the 'end's? If the latter, set your
editor's syntax highlighting to grey them to near-invisibility - that
way it'll indent everything properly, and you won't see the actual 'end'
in your code.
martin
Jim McFarland
>
> I don't even think about them. I just use the language as it is.
>
That sums up my opinion on "end" in Ruby as well.
later...
jim
Luke Duncalfe
Luke Duncalfe
>"Serdar Kiliç" <ski...@gmail.com> wrote in message
>news:9bff2786060201...@mail.gmail.com...
>Honestly, I prefer ENDs to indentation, I prefer curly braces to ENDs.
>But how about something like this:
>def foo
> @var
>}
Oooh. Now I found quite attractive. It's like a single bookend keeping
things upright between itself and the wall.
Rubyist
Hakkaten de fena fikir degilmis...
Yukihiro Matsumoto
In message "Re: Indentation vs. "end"s"
on Thu, 2 Feb 2006 15:07:27 +0900, Hal Fulton <hal...@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.
matz.
Yukihiro Matsumoto
In message "Re: Indentation vs. "end"s"
on Thu, 2 Feb 2006 06:37:02 +0900, "Rubyist" <nuby.ruby....@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.
matz.
Cameron McBride
On 2/2/06, Yukihiro Matsumoto <ma...@ruby-lang.org> wrote:
> 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?
Cameron
Serdar Kılıç
believe that the curly brace to END is a decent option as it already
is familiar to many others. In most other languages the semicolon
denotes an end to a statement which for newbies (such as myself) it
may get confusing.
Yukihiro Matsumoto
On 2/3/06, Cameron McBride <cameron...@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.
matz.
Jeffrey Schwab
> I'm out of my league, but...
>
> On 2/2/06, Yukihiro Matsumoto <ma...@ruby-lang.org> wrote:
>
>>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.
MenTaLguY
> > 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.
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.
-mental
James Edward Gray II
> On Fri, 2006-02-03 at 12:46 +0900, Yukihiro Matsumoto 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.
>
> 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.
James Edward Gray II
Rubyist
>> 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.
def foo()
blah blah
if blah blah
blah blah }
}
Ross Bamford
> On Feb 2, 2006, at 10:07 PM, MenTaLguY wrote:
>
> > On Fri, 2006-02-03 at 12:46 +0900, Yukihiro Matsumoto 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.
> >
> > For what it's worth, I also strongly dislike it.
>
+1
> Amen brother.
>
> I don't think Ruby ever needs to be ashamed of being Ruby.
>
+1
Robert Klemme
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
furu...@ccsr.u-tokyo.ac.jp
[. . .]
> I haven't liked them. But curly braces may me quite better.
>
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
Kroeger, Simon (ext)
> if (cond) {meth this; func that} #(2)
how about:
(puts 'this'; puts 'that') if true
cheers
Simon
Mark Volkmann
>
> > if (cond) {meth this; func that} #(2)
>
> how about:
>
> (puts 'this'; puts 'that') if true
I'll chime in and say that I also don't like the ";;" idea.
I've always thought that parens could be used better, so I like
Simon's suggestion. In fact, if I were designing a language from
scratch, I'd use parens differently for method calls.
Instead of
calculate_average(19, sum(4, 7), 3)
I'd make it
calculate_average 19 (sum 4 7) 3
Parens would only be used to group method names with arguments when
there is more than one method call on the same line. Commas aren't
even necessary. Of course this is too drastic of a change to make to
Ruby at this point.
--
R. Mark Volkmann
Partner, Object Computing, Inc.
Thomas Kirchner
> 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
Mark Volkmann
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.
Thomas Kirchner
> 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
Dirk Meijer
> if we do end up using them
in this discussion, a sentence with the words 'do' and 'end' is hard to read
properly :P
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 :P
greetings, Dirk
Michal Suchanek
> dou...@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.
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
Sky Yin
> 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.
Doug H
Sky Yin wrote:
> >
> > 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?
end do
Thomas Kirchner
> > (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 <something>" should refer to the actual construct
you're ending, not just a keyword.
Either way, I think it's ugly ;)
Tom
furu...@ccsr.u-tokyo.ac.jp
>
> how about:
>
> (puts 'this'; puts 'that') if true
Thanks for the suggestion. That may be a good
solution for this particular case. But, how about
if condy then pet bush else bash him end #(3)
? Well, I think our main point is not how we can
come up with a nice looking construct for each case,
but what normal, regular constracts look like.
Regards,
Ryo
Michael Sullivan
Sky Yin
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?
Doug H
Thomas Kirchner wrote:
> * On Feb 4 4:28, Doug H (ruby...@ruby-lang.org) 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 <something>" should refer to the actual construct
> you're ending, not just a keyword.
You're ending a closure block, which starts with "do".
Wilson Bilkovich
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
Dirk Meijer
>
> 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
best solution i've seen so far! *sticks thumb up* i think i'll start using
that too :-)
Luke Duncalfe
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" <ma...@ruby-lang.org> wrote in message
news:1138877284.580712...@x31.priv.netlab.jp...
> matz.
>
>
gabriele renzi
>>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.
Eustaquio Rangel de Oliveira J
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.
Check http://www.python.org/doc/essays/styleguide.html.
----------------------------
Eustáquio "TaQ" Rangel
eustaqu...@yahoo.com
http://beam.to/taq
Usuário GNU/Linux no. 224050
Sung Soo Kim
> >>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 :P )
David Vallner
> Austin Ziegler ha scritto:
> > I prefer explicit -- and more flexible -- than implicit and
> > inflexible.
>
>
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
David Vallner
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:
joesb
dou...@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.
tony summerfelt
> class Foo
> def bar(a)
> p a
> ;;
> ;;
ooh, i like that.
> p a;;;;
speaking for myself, i wouldn't write code like that. but i do like
the semi colon idea
--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
joesb
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.
Hal Fulton
> 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.
I think I like this. If it were an RCR, I just might vote for it.
But I would want two things:
1. Not too much proliferation, please. "is" and "do" are enough.
2. Let's make it clear that "is/end" and "do/end" shall behave
exactly the same way. No subtle differences, please.
This almost makes me want an alias_keyword... but that would probably
cause more problems than it would solve.
Hal
chiaro scuro
> > I think I like this. If it were an RCR, I just might vote for it.
> >
> > But I would want two things:
> > 1. Not too much proliferation, please. "is" and "do" are enough.
> > 2. Let's make it clear that "is/end" and "do/end" shall behave
> > exactly the same way. No subtle differences, please.
> >
> > This almost makes me want an alias_keyword... but that would probably
> > cause more problems than it would solve.
I definitely wouldn't want that. I really feel that "less is more".
> Less keywords, not more, will result in less confusion.
>
>
I would love the is|do aliasing. Expressive code should be a primary
concern.
It also seems to be in line with the philosophy of the ruby libraries, the
if/unless constructs, etc..
-- Chiaroscuro --
Liquid Development Blog:
http://feeds.feedburner.com/blogspot/liquiddevelopment
Lionel Thiry
def some_method = ->(args) {
# some code
}
:-p
--
Lionel Thiry
Personal web site: http://users.skynet.be/lthiry/
Gregory Seidman
} Mark Volkmann a ?crit :
You appear to be joking, but I'd kind of like that. I'd love to be able to
enclose *all* my scopes in curly braces and never type do/is/end at all.
I'm sure this comes of a C-syntax-centric worldview, but I'd love it.
module Foo {
def bar() {
#...
if (something) {
} elif (something_else) {
} else {
}
}
#...
}
class Baz {
include Foo
#...
}
} Lionel Thiry
--Greg
Peter Hickman
NOT EVERYONE HAS ENGLISH AS A FIRST LANGUAGE!!!!!
It may be expressive in English but for some people it is just an arbitrary
sequence of symbols.
Bring back APL, that's what I say :-)
Austin Ziegler
> Austin Ziegler 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? :)
Doubtful. I don't follow Pythonistas. However, if they are at all
serious about it, the irony involved in their *own* failure to be
explicit is delicious.
> > 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.
I've never had that feeling. I've programmed in too many different
programming languages to feel that there's anything "wrong" with them.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca