Parser error when trying to make a method private

I defined the following  method  for Object:

  <- arg
  "
  a simple binary method, with empty method-body
  "

This compiled fine on Dolphin 5.1 and also executes
ok. But I then tried to mark the method PRIVATE from
the menu. This caused a parser error "variable name expected".

In the debugger, the method that triggered the error was:

    parseVariableNode
        currentToken isIdentifier
            ifFalse: [self parserError: CErrExpectVariable].
        ^self parsePrimitiveIdentifier


The value of 'currentToken' was:   StBinarySelectorToken(#-)

Thanks
-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:[hidden email]...
This is because the RB parser (used for performing context [node] sensitive
operations on method source such as code refactorings, reformatting, etc)
does not accept #<- as a valid binary selector, whereas the old Dolphin
compiler does. In this case I think the Dolphin compiler is right (ref ANSI
standard section 3.5.5). The case where such a selector is used with a
negative number as its argument is disambiguated by requiring a space
between the binary selector and the negative number.

So there are two bugs:
1) RB parser should not be treating binary selectors ending in a trailing
'-' as an error (#1604)
2) The Categories/Private command should be disabled if the method cannot be
compiled (#1605).

Thanks for the report.

Blair

Blair McGlashan wrote:

> 2) The Categories/Private command should be disabled if the method cannot
> be compiled (#1605).

Why not just fall back to the non-RB implementation in such cases ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair McGlashan wrote:
>
>> 2) The Categories/Private command should be disabled if the method cannot
>> be compiled (#1605).
>
> Why not just fall back to the non-RB implementation in such cases ?
>

Because that would only address the issue where the parsers disagree. Since
the short term aim is to eliminate any differences that are found, and the
medium term aim is to eliminate the Dolphin parser altogether, that would
only be of temporary relevance. Going forward there will always be cases
where methods might not be compilable, either because they weren't when the
code was loaded or because of subsequent (non-refactoring) changes. Since
the purpose of the command is to include a comment to the effect that the
method is private (or remove it if toggling off privacy), it has to modify
the source. This is only really safe if the method can be parsed, so when it
isn't the command should be disabled.

Regards

Blair