Multiple types in implements statement are not fully supported

[Idriss Riouak]

If a class implements more than one interface, Jastadd generates code that does not compile.

aspect Test{
    public interface B{}
    public interface C{}

    A implements B , C;

    coll Set<B> B.set()[Collections.emptySet()] with add;
    A contributes this to B.set() for each Collections.singleton(this);
}

This because during the parsing of 'A implements B , C;' what follows 'implements' is treaded as a unique token.
A possible workaround is to split A implements B , C; in A implements B; and A implements C;.

‌

Below the error generated by javac:

A.java:45: error: cannot find symbol
contributorMap_B_set = null;
^
symbol:   variable contributorMap_B_set
location: class A

error: cannot find symbol
super.collect_contributors_B_set(_root, _map);
      ^
symbol: method collect_contributors_B_set(A,Map<ASTNode,Set<ASTNode>


error: cannot find symbol
super.contributeTo_B_set(collection);
      ^
symbol: method contributeTo_B_set(Set<B>)

Attached you can find a small test case.

[Jesper Öqvist]

Is it not possible to just write this:

A implements B;
A implements C;

It seems redundant to add this new variant of the implements statement just to allow multiple interfaces (in a single line) if it is already possible in this way (with multiple lines).

[Jesper Öqvist]

I added a test that verifies that the implements statement can add multiple interfaces: https://bitbucket.org/jastadd/jastadd-test/commits/5553ec3be124a2bbf3fead568eccd808105f743d

[Idriss Riouak]

Yes is it possible to write this:

A implements B;
A implements C;

But, if you can write

A implements B, C;

Then the code is more easy to maintain.
For example, I have a situation where I need do specify that some ASTDecl implements two or more interfaces. This would be like this:

A_1 implements I_1, I_2, ..., I_m
A_2 implements I_1, I_2, ..., I_m
...
A_n implements I_1, I_2, ..., I_m

instead of NxM implements statements.

Personally, I think that can be useful to have this kind of ‘feature’ .
On the contrary, if we decide to avoid this kind of statement then we need to handle and generate an appropriate error if the lookup at line 109 of Grammar.jrag (https://bitbucket.org/jastadd/jastadd2/src/1d235fb78d7094f66d929f24e0cad841c97f6635/src/jastadd/ast/Grammar.jrag) is null.

[Jesper Öqvist]

Then the code is more easy to maintain.

I do not see how maintainability is improved by being able to compress multiple implements statements into a single line.

The example you give seems like it comes from generated code in which case it wouldn’t matter much how the implements clauses look.

[Jesper Öqvist]

I overlooked the fact that the parser actually already accepts multiple types after “implements”, which means that you can use the multiple interface version just that they are not recognized as implemented interfaces during attribute weaving and code generation (apart from being pretty-printed in the class declaration).

I would have preferred to just remove the multiple interface version from the parser since it seems like an unnecessary feature that just adds complexity/bloat, but since this already semi-works the best solution is maybe to make it actually work.

[Jesper Öqvist]

If fixing this “properly” takes too much work (splitting types correctly with parameterized types), I would suggest just removing multiple types in the parser - an easy fix.

[Jesper Öqvist]

[parser] Improve handling of multiple interfaces in implements statement

fixes #324

→ <<cset faf36d223363>>