Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325658

Summary:	AbstractRule and AbstractElement should have a common base class
Product:	[Modeling] TMF	Reporter:	Karsten Thoms <karsten.thoms>
Component:	Xtext Backlog	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P5	CC:	moritz.eysholdt, sebastian.zarnekow, sven.efftinge
Version:	1.0.1
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X
Whiteboard:

Description Karsten Thoms

2010-09-17 17:02:40 EDT

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".

Comment 1 Sebastian Zarnekow

2010-09-17 18:56:08 EDT

What features do you expect on AbstractGrammarElement?

Comment 2 Sebastian Zarnekow

2010-10-05 09:18:23 EDT

Please reopen if I missed an important usecase.

Comment 3 Moritz Eysholdt

2010-10-05 15:38:40 EDT

(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.

Comment 4 Sven Efftinge

2010-10-06 03:00:32 EDT

I think the points are valid and adding a super type for both isn't a big deal.

Comment 5 Karsten Thoms

2016-03-29 10:47:15 EDT

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.
"

Comment 6 Eclipse Webmaster

2017-10-31 11:23:51 EDT

Requested via bug 522520.

-M.