class Foo
def bar
puts 'bar'
if foo
endif
enddef
endclass
I'm only suggesting this as an option to ruby -c
like
ruby -c -check_extended_end
still we make endclass/enddef/endif synonyms to end, thus programmer is free
to use them or not.
and w regards to indents
ruby -c -check_indent
Again, programmer is free to use indents (as syntax check) or not.
kind regards -botp
···
Randy W. Sims [mailto:ml-ruby@thepierianspring.org] wrote:
Like another poster, I'm in the habit of writing the close marker
immediately after the open marker. However, one style guide I
sometimes
follow is that if a block exceeds one "page" or if I have some deeply
nested code, I will comment the end(s):
class Foo
def bar
puts 'bar'
end#bar
end # class Foo
I'm only suggesting this as an option to ruby -c
like
ruby -c -check_extended_end
still we make endclass/enddef/endif synonyms to end, thus programmer is free
to use them or not.
and w regards to indents
ruby -c -check_indent
Again, programmer is free to use indents (as syntax check) or not.
kind regards -botp
Perhaps they shouldn't be strict equivalents. I'd prefer that endclass NOT be able to close an if statement. But as long as the generic end statement was retained, then which variant to use could be a matter of taste and circumstance. And if we're going to go in that direction, the perhaps the class/routine name could be an optional parameter. This could result in something like:
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
enddef bar
endclass Foo
Or perhaps we would better merely give end some default parameters, optionally looking like
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
end def bar
end class Foo
Though that itself could lead to a few new problems. Still formatting errors that were detected at compile time wouldn't be too onerous.
The question is, how much work would any of these ideas be to implement, and what, if any, existing code would they break. (Offhand it looks simple and safe, but I'm no expert in THAT area.) Also, it it esthetically nice, though perhaps the importance of that is minimal, as one consideration is that all existing code should continue to work.
I feel that I'd probably continue to code a I currently do, except when an error was detected. Then I would find the greater simplicity in tracing it down to override any esthetic damage caused by the "excess" verbage.
···
Randy W. Sims [mailto:ml-ruby@thepierianspring.org] wrote:
I don't even know C and I was able to put together a patch that
makes lady's blush and strong men weep (see adjacent threads) in about
three light evenings work.
-- Markus
···
On Fri, 2004-10-08 at 12:48, Charles Hixson wrote:
The question is, how much work would any of these ideas be to
implement, and what, if any, existing code would they break.
(Offhand it looks simple and safe, but I'm no expert in THAT
area.) Also, it it esthetically nice, though perhaps the
importance of that is minimal, as one consideration is that
all existing code should continue to work.
I'm only suggesting this as an option to ruby -c
like
ruby -c -check_extended_end
still we make endclass/enddef/endif synonyms to end, thus programmer is free
to use them or not.
and w regards to indents
ruby -c -check_indent
Again, programmer is free to use indents (as syntax check) or not.
kind regards -botp
Perhaps they shouldn't be strict equivalents. I'd prefer that endclass NOT be able to close an if statement. But as long as the generic end statement was retained, then which variant to use could be a matter of taste and circumstance. And if we're going to go in that direction, the perhaps the class/routine name could be an optional parameter. This could result in something like:
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
enddef bar
endclass Foo
Or perhaps we would better merely give end some default parameters, optionally looking like
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
end def bar
end class Foo
Though that itself could lead to a few new problems. Still formatting errors that were detected at compile time wouldn't be too onerous.
The question is, how much work would any of these ideas be to implement, and what, if any, existing code would they break. (Offhand it looks simple and safe, but I'm no expert in THAT area.) Also, it it esthetically nice, though perhaps the importance of that is minimal, as one consideration is that all existing code should continue to work.
I feel that I'd probably continue to code a I currently do, except when an error was detected. Then I would find the greater simplicity in tracing it down to override any esthetic damage caused by the "excess" verbage.
I don't feel strongly about the issue as I rarely run into trouble since I close a block immediately after opening it (free memory after allocating, close filehandles after opening, etc). If Ruby were to be extended, I would suggest that it be completely optional and only used as a hint to the parser about the structure of the code. I like the form:
end [(class|module|def) [<NAME>]]
IOW, it applies only to high level blocks and is optional. Additionally the name of the entity being closed can be named, the name of the method, class, or module. whitespace seperates all elements.
I think it a simple and useful addition to Ruby.
Randy.
···
Randy W. Sims [mailto:ml-ruby@thepierianspring.org] wrote:
I like very much Charles' idea:
Modify "end" so that it takes optional arguments:
end if
end do
end class Food
end def eat
Advantages:
- it's optional,
- it doesn't break any older code
- I suppose it's easy to implement
- I suppose it's easy to write an emacs routine that
automatically inserts (or deletes) theses arguments
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
end #bar
end #Foo
in much of my code for sanity sake. A -c check on those kind of remarks might
do the trick, yes?
T.
···
On Friday 08 October 2004 03:48 pm, Charles Hixson wrote:
Or perhaps we would better merely give end some default parameters,
optionally looking like
class Foo
def bar
puts 'bar'
if foo
.... stuff....
endif
end def bar
end class Foo