#467 Allow trailing "=" on method names without quoting

[Rick McGuire]

On the ::method directive, it would make the code more readable if the syntax for the method name allowed a trailing "=" on the name without quoting. The following pattern is very common with method names:

::method firstChild abstract
::method "firstChild=" abstract

It seems strange to the eyes that the second needs to be quoted. A much nicer solution would be:

::method firstChild abstract
::method firstChild= abstract

which has a lower astonishment factor and reads nicer.

[Moritz Hoffmann]

Is this all it needs? (line offsets might not be correct due to other local changes)

Index: interpreter/parser/SourceFile.cpp
===================================================================
--- interpreter/parser/SourceFile.cpp   (revision 9914)
+++ interpreter/parser/SourceFile.cpp   (working copy)
@@ -2167,7 +2167,8 @@
     RexxString *name = token->value; /* get the string name               */
                                      /* and the name form also            */
     RexxString *internalname = this->commonString(name->upper());

-    for (;;)
+    bool firstOption(true);
+    for (;;firstOption = false)
     {                       /* now loop on the option keywords   */
         token = nextReal();            /* get the next token                */
                                        /* reached the end?                  */
@@ -2175,6 +2176,9 @@
         {
             break;                       /* get out of here                   */
         }
+        else if (firstOption && token->subclass == OPERATOR_EQUAL) {
+            internalname = internalname->concatToCstring("=");
+        }
                                          /* not a symbol token?               */
         else if (!token->isSymbol())
         {

[Anonymous]

I'm afraid it is more complicated than this, since the scanning rules for whitespace removal will have already removed blanks. The "=" in question needs to be directly part of the token involved. I think there is very much less need for this enhancement now that abstract can be specified on the ::attribute directive with 4.2.0.

[Moritz Hoffmann]

Yep, was thinking the same. Maybe we should close the feature request as this feature is not really needed anymore. Otoh, if we support the equal sign, we'd also have to support the array accessor "[]" and assignment operators without quotes. So it might really be easier at the moment to keep it that way. Looking at the parser, it's not straight forward to implement it to avoid white space.

[Rick McGuire]

Now that ::attribute supports an abstract option, there is a lot less need for this this. Since it would introduce some new tokenization behavior, I think this can be closed.