Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Inheriting grammar vs. reusing project
Inheriting grammar vs. reusing project [message #543374] Tue, 29 June 2010 09:01 Go to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 671
Registered: July 2009
Location: Trondheim, Norway
Senior Member
Hi,

I was debugging a strange problem concerning terminals, yesterday. I got
an error marker only containing "java.lang.String", which looked like an
casting problem. Hence, I added breakpoints to the relevant
(declarative) value converter. It wasn't called. Then I moved the
breakpoint up the inheritance chain and found out that the value
converter wasn't registered.

This particular terminal was inherited from a grammar, for which there
was bound a custom IValueConverterService. But the binding wasn't
inherited automatically, e.g. by subclassing the inherited project's
runtime module.

I would guess this is a common problem, since inheriting/reusing a
grammar is so common. One solution could be to model inheritance and
custom bindings explicitly, so the generated code could include
references to inherited bindings. Is there any plans for something like
this?

Hallvard
Re: Inheriting grammar vs. reusing project [message #543510 is a reply to message #543374] Tue, 29 June 2010 16:04 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Hallvard Trætteberg schrieb:
> Hi,
>
> I was debugging a strange problem concerning terminals, yesterday. I got
> an error marker only containing "java.lang.String", which looked like an
> casting problem. Hence, I added breakpoints to the relevant
> (declarative) value converter. It wasn't called. Then I moved the
> breakpoint up the inheritance chain and found out that the value
> converter wasn't registered.
>
> This particular terminal was inherited from a grammar, for which there
> was bound a custom IValueConverterService. But the binding wasn't
> inherited automatically, e.g. by subclassing the inherited project's
> runtime module.
>
> I would guess this is a common problem, since inheriting/reusing a
> grammar is so common. One solution could be to model inheritance and
> custom bindings explicitly, so the generated code could include
> references to inherited bindings. Is there any plans for something like
> this?

Yes, for now, you'll have to compose the different aspects manually, if
you have done things in your super grammar.
As we are going to develop a base language for Xtext in the next release
cycle we'll definitely have a look into how to better support this.

Sven

--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : blog.efftinge.de
Re: Inheriting grammar vs. reusing project [message #1404252 is a reply to message #543510] Wed, 30 July 2014 16:07 Go to previous messageGo to next message
Pedro Isidro is currently offline Pedro IsidroFriend
Messages: 2
Registered: July 2014
Junior Member
I am currently facing the same problem. Has this issue been fixed?
Re: Inheriting grammar vs. reusing project [message #1404261 is a reply to message #543510] Wed, 30 July 2014 17:36 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6538
Registered: July 2009
Senior Member
Hi Sven

For OCL, I need grammar modularity and extensibility and so I have been
thinking about a slightly extended SuperXtext comprising a SuperXtext to
Xtext model to model transformation thereby avoiding any modification to
Xtext tooling.

To control name collisions I envisaged that by default a 'Rule' in an
imported 'Grammar' would be automatically renamed as 'Grammar'_'Rule'
avoiding any collisions unless a 'Rule' redefines or extends another
rule. 'redefines' is a simple total replacement of the new name for all
old renames. 'extends' creates a merging rule so that grammars extend
like yacc or LPG.

Punctuation-separated-lists are common so I planned to extend the
spec-separated-list * cardinality with a suffix *:'separator'. Of course
it would be better to support this directly in Xtext.

It would be great if you do this for me...

Regards

Ed Willink

On 29/06/2010 17:04, Sven Efftinge wrote:
> Hallvard Trætteberg schrieb:
>> Hi,
>>
>> I was debugging a strange problem concerning terminals, yesterday. I
>> got an error marker only containing "java.lang.String", which looked
>> like an casting problem. Hence, I added breakpoints to the relevant
>> (declarative) value converter. It wasn't called. Then I moved the
>> breakpoint up the inheritance chain and found out that the value
>> converter wasn't registered.
>>
>> This particular terminal was inherited from a grammar, for which
>> there was bound a custom IValueConverterService. But the binding
>> wasn't inherited automatically, e.g. by subclassing the inherited
>> project's runtime module.
>>
>> I would guess this is a common problem, since inheriting/reusing a
>> grammar is so common. One solution could be to model inheritance and
>> custom bindings explicitly, so the generated code could include
>> references to inherited bindings. Is there any plans for something
>> like this?
>
> Yes, for now, you'll have to compose the different aspects manually,
> if you have done things in your super grammar.
> As we are going to develop a base language for Xtext in the next
> release cycle we'll definitely have a look into how to better support
> this.
>
> Sven
>
Previous Topic:Strange he path 'ControlFlow.irl' is unmapped
Next Topic:ANTLR development?
Goto Forum:
  


Current Time: Thu Dec 12 22:43:26 GMT 2019

Powered by FUDForum. Page generated in 0.01383 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top