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

Bug 316862

Summary:	feature initialization definable in grammar rule
Product:	[Modeling] TMF	Reporter:	Robert Wloch <robert>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	bojidar.dimitrov, robert, sebastian.zarnekow, sven.efftinge
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Robert Wloch

2010-06-15 04:24:55 EDT

In order to be more flexible with grammars for existing domain models, I'd like to be able to define inital values for features in the grammar. Please, consider this example:

[CODE]
Interface returns myModel::Class:
    'interface' name=ID interface?=INITIALIZE(true)
    ('extends' implementedTypes+=Type
    	(',' implementedTypes+=Type)*
    )?;

Class returns myModel::Class:
    'class' name=ID interface?=INITIALIZE(false)
    ('extends' superTypes+=Type
    	(',' superTypes+=Type)*
    )?
    ('implements' implementedTypes+=Type
    	(',' implementedTypes+=Type)*
    )?;
[/CODE]

It shows how one could implizitely initialize a boolean feature "interface". But a similar approach should also work for strings, numbers, or cross references.
I mentioned that request already in the newsgroup: http://www.eclipse.org/forums/index.php?t=msg&th=170024&start=0&

Cheers
Rob

Comment 1 Bojidar

2010-07-21 04:10:02 EDT

I too would like to have this feature!  It would allow much easier generator rules and some things which right now are not (easily) possible.

Here is my example:

Person: 
        name=ID canTalk?=INITIALIZE(true);

Parrot: 
        name=ID canTalk?='canTalk'; 

Mouse: 
        name=ID canTalk?=INITIALIZE(false); 

Participant: 
        Person | Parrot | Mouse; 

I am using the syntax proposed by Robert, but surely shorter syntax could be invented.  The advantage of this initialization is that now all three participants have a boolean feature canTalk and this is uplifted in Participant, so now I can write a define like this:

«DEFINE main FOR Participant» 
     «IF canTalk»Participant «name» can talk. «ENDIF» 
«ENDDEFINE» 

Of course, I could solve the problem with the current features of XText by using extensions, but by far not as elegantly as the example above.

And using the proposed grammar above, I can also write model checks (*.chk) for a Participant, and for checks it seems impossible to use extensions (at least I was not able to get them to work), so the proposed grammar extension seems to be the only solution.

Comment 2 Sven Efftinge

2010-09-27 09:07:37 EDT


*** This bug has been marked as a duplicate of bug 326298 ***