Inheriting grammar vs. reusing project [message #543374] |
Tue, 29 June 2010 09:01 |
Hallvard Traetteberg Messages: 673 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 |
Sven Efftinge 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 #1404261 is a reply to message #543510] |
Wed, 30 July 2014 17:36 |
Ed Willink Messages: 7655 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
>
|
|
|
Powered by
FUDForum. Page generated in 0.03189 seconds