Description Chris Holmes 2010-06-02 03:27:49 EDT

The text below is taken from the initial post via the news group:

<snip>
Hi Chris,

This is an interesting bug indeed :)

Apparently, nesting many else if statements really kills the parser. An ugly workaround is to use if () {} else { if () ... } instead. E.g.

if (i == 1) {

} else if (i == 2) {

} else if (i == 3) {

}

should be rewritten as

if (i == 1) {

}
else {
  if (i == 2) {

  }
  else {
    if (i == 3) {

    }
  }
}

This explains all the symptoms you're encountering. I'll have a look at the grammar of EOL to see if I've done something stupid (which I most probably have). Could you please file a bug report for this?

Cheers,
Dimitris

On 01/06/2010 19:02, Dimitris Kolovos wrote:
> Hi Chris,
>
> I'll have a look at this and get back to you shortly.
>
> Cheers,
> Dimitris
>
> Chris Holmes wrote:
>> Hi,
>> I have a transformation that (amongst other things) calls an operation
>> to complete some associations between a target model and a referenced
>> model. The operation in question takes the form:
>>
>> operation Target!MyContext myOperation(myRef : Reference!SomeContext) {
>> if(self.number == 1) {
>> 'bind item 1'.println();
>> } else if(self.number == 2) {
>> 'bind item 2'.println();
>> } ... etc
>> }
>>
>> The operation has approx. 22 'else' clauses. Curiously, this seems to
>> bring Eclipse to it's knees. The introduction of this change appears
>> to increase the run time of the transformation from seconds to
>> minutes, saving the file in Eclipse takes minutes, and Eclipse even
>> boots up very slowly if this structure is present.
>>
>> Is there a better (more efficient) way of representing the semantics
>> of 'myOperation' in EOL?
>>
>> Regards
>> Chris
</snip>

Perhaps an easier solution to such pathological cases would be to introduce a 'switch' statement?

Chris