From: Charles Hixson <charleshixsn@...>
Date: 2004-10-09T04:48:11+09:00
Subject: Re: quality of error messages

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.