Randy W. Sims
10/8/2004 8:22:00 PM
Charles Hixson wrote:
> Peña, Botp wrote:
>
>> Randy W. Sims [mailto:ml-ruby@thepierianspring.org] wrote:
>> ...
>>
>> 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.