Home » Modeling » TMF (Xtext) » Supporting Refinement behavior
| Supporting Refinement behavior [message #556547] |
Wed, 01 September 2010 17:15  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
I'm not sure that Refinement is quite the way to describe what I want to do -- Mixin perhaps. I wonder if there is any built-in support or suggested patterns that would support the following usage. I'd like to provide a way to allow the extension of types seamlessly.
imagine the following language L with a simple grammar defining Classes that can have attributes.
MyThing {
integer Age,
double Wealth
}
...
^MyThing {
boolean StarBellied
}
Here, we'd like to end up with an Object definition for MyThing {Age, Wealth, StarBellied} such that we can refer to the attribute "StarBellied" just as we'd refer to any other attribute. Note that this is *not* the same as defining an extension to MyThing. It is the same model entity.
So in XText, we'd need to define a grammar like:
Class :
ClassID=ID
(attributes += Attribute ("," attributes += Attribute)*)?
But for the second, the following approach would of course not work:
Class :
"^" RefinedClass=[Class]
(attributes += Attribute ("," attributes += Attribute)*)?
Now, we could define a:
RefiningClass :
"^" RefinedClass=[Class]
(attributes += Attribute ("," attributes += Attribute)*)?
But here we'd have to add scoping and linking logic to allow any references to refined attributes to be used just like regular class attributes, and I'm not sure that you could get that to work well, especially for quick content assist, etc..
Ideas or something I've Missed?
-Miles
[Updated on: Wed, 01 September 2010 17:16] Report message to a moderator |
|
| | |
| Re: Supporting Refinement behavior [message #556800 is a reply to message #556725] |
Thu, 02 September 2010 16:25  |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Thanks guys..
| Meinte Boersma wrote on Thu, 02 September 2010 09:06 | I'd definitely go for a m2m-approach here (as Alexander suggests): have a grammar with both Class and RefinedClass rules and such, a second (Ecore) metamodel and a m2m transformation to gather all info. Fornax/Sculptor uses such an approach do some normalizations and convenient changes of meta type name of the input DSL text before going into the generator.
|
But as Alexander brings up, wouldn't we lose a lot of the tooling in the process? IOTW, let's say I then want the user to be able to use a reference to MyThing.StarBellied. How would code completion be supported in this context?
| Quote: | A grammar should not really concern itself (overly) with semantics -a good editing experience is way more important than getting the underlying semantics right and that's difficult enough on its own, IMHO..
|
Yes, that has been my experience as well. I've found that attempts to make an existing Ecore model directly into a grammar ends up being very unnatural and difficult to maintain even if you can get it working correctly. For this reason, while I like the idea of having say a common representational structure for say graphical and textual languages, it often doesn't work very well in practice. Instead I think it makes a lot of sense to think of having a model that simply represents the presentation and transformation of the language itself.
Getting off topic a bit, but I have managed to get a hybrid working in this case where most objects are the target model and some are used as intermediate glue or expansions, but unfortunately I'm finding that because Ecore models are all sealed that navigating references between the two models often is not possible.
|
|
| |
| Re: Supporting Refinement behavior [message #556841 is a reply to message #556830] |
Thu, 02 September 2010 19:01 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Alexander Nittka wrote on Thu, 02 September 2010 14:01 |
You reference an Attribute directly, i.e. rather than
[Class]'.'[Attribute] you use [Attribute|QualifiedName], having a qualified name provider that uses as the name of an attribute the <NameOfClass>.<NameOfAttribute> only that in one case the name of the class is in fact the name of the referenced class.
|
Thanks, I did miss that. I was hoping for a solution where I could use the same constructs everywhere. Actually, I realized that was a bad example case, because usually I will be finding the reference purely based on context. So that seems like the most work will be on the scoping side. In particular, you might want to support references to refined classes and other classes from refined classes for example, so in that case you'd have to walk up and across the tree to find all possibilities. Actually, that's the kind of thing that the XTet scoping mechanism is designed for. But the grammar on the other hand could get pretty complex. It's an interesting design challenge I think.
|
|
|
| Re: Supporting Refinement behavior [message #556918 is a reply to message #556547] |
Fri, 03 September 2010 07:45 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Hi Miles,
Am 9/1/10 7:15 PM, schrieb Miles Parker:
> I'm not sure that Refinement is quite the way to describe what I want to
> do -- Mixin perhaps. I wonder if there is any built-in support or
> suggested patterns that would support the following usage. I'd like to
> provide a way to allow the extension of types seamlessly.
> imagine the following language L with a simple grammar defining Classes
> that can have attributes.
>
>
> MyThing {
> integer Age,
> double Wealth
> }
>
> ..
>
> ^MyThing {
> boolean StarBellied
> }
>
>
> Here, we'd like to end up with an Object definition for MyThing {Age,
> Wealth, StarBellied} such that we can refer to the attribute
> "StarBellied" just as we'd refer to any other attribute. Note that this
> is *not* the same as defining an extension to MyThing. It is the same
> model entity.
Why does it need to be the same object? Why care about the internal
state, what matters is the abstraction.
You should make the extension concept a language construct.
And whenever you refer to an attribute, you should have clear semantics
of which extensions apply (global scope vs. lexical scope, i.e. explicit
import of extensions come to my mind).
That should be done in the scoping rules for the Attribute reference.
Shouldn't be too hard.
Sven
--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de
|
|
|
| Re: Supporting Refinement behavior [message #557018 is a reply to message #556918] |
Fri, 03 September 2010 16:09 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi Sven, see below please..
| Sven Efftinge wrote on Fri, 03 September 2010 03:45 |
Why does it need to be the same object? ...
That should be done in the scoping rules for the Attribute reference.
Shouldn't be too hard.
|
This was of course a simplifying assumption. In fact there are a number of constructs. So best case I will need to maintain a somewhat duplicate grammar twice in the best case. But I think it almost all cases it is going to be quite a bit more complex. Consider, if I have a target model object like:
ValueSetter {
Class thing;
Attribute value;
}
Now, with this new version, I'm going to have to do something like:
ValueSetter :
(Class thing | ClassExtension thing)
Attribute value;
And of course I could often make Class and ClassExtension use a common root. Then when scoping I could check if the parent node is a class or class extension and do the scoping on that.
But the main limitations I keep coming back to are all based on the problem that I'm dealing with an existing Ecore model, so that all of my classes are sealed. This is a real pain because it means that as soon as I get into the level of the model that is just below the "Extension" abstraction, I can't add any new details to the entities themselves and I cannot refer to these different objects in the constructs anywhere.
This is the kind of thing that comes up again and again when trying to do a mapping to an existing Ecore model. The basic language constructions work for all of the simple cases, but since there is no way to either a) extend an existing Ecore EClass or b) create a class that "pretends" to fit the needed type and then is handled at scope / link time.
What would be really neat is the ability to say for example "here's my pseudo-class PClass -- it doesn't look at all like Class, but here's the transformer that you can use to turn it onto one." Another *extremely* useful capability would to be able to create overloaded / unsealed Rules for Ecore classes that allow the addition of elements. That would allow you to add extra semantics that could then be used at scoping and linking time to determine what to do with them.
But absent that I can't think of any way to get what I want short of completely re-implementing the entire Ecore model in XText..
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:22:49 GMT 2024
Powered by FUDForum. Page generated in 0.04373 seconds |
] 
Search
Help
Register
Login
Home
