Community
Participate
Working Groups
CompositeNode.getGrammarElement() returns just EObject, which is a bit ugly, since effectively it can be just an instance of AbstractRule or AbstractElement. Therefore it would be cleaner if getGrammarElement() could return a more specific type, like "GrammarElement" or "AbstractGrammarElement".
What features do you expect on AbstractGrammarElement?
Please reopen if I missed an important usecase.
(In reply to comment #1) > What features do you expect on AbstractGrammarElement? None. The use case is to have an actual type for scenarios where "either an AbstractRule or an AbstractElement" is required. As Karsten mentiones, this is the case for CompositeNode.getGrammarElement() Another use case is the formatter: The methods invoked to build a formatting config in AbstractFormattingConfig.ElementLocator, such as before(...), after(...), between(... ,...) currently all accept parameters of EObject. Actually, an AbstractElement or AbstractRule is required. It would be nice to have better static typing for this scenario. I think it helps people to understand the API. Using EObject feels like no typing at all.
I think the points are valid and adding a super type for both isn't a big deal.
Pull Request https://github.com/eclipse/xtext/pull/974 was rejected. Review comment from Sven Efftinge: "It breaks binary compatibility so it is not ok. In general this PR includes lots of changes that could introduce problems without a significant improvement on the other side. I think we should close that old bug. It's just too much noise for the little benefit today. "
Requested via bug 522520. -M.
