Home » Modeling » EMF » [xcore] A textual language for Ecore
| |
| Re: [xcore] A textual language for Ecore [message #714158 is a reply to message #713987] |
Tue, 09 August 2011 23:02   |
Eclipse User |
|
|
|
Originally posted by:
Continuing the thread from the blog post:
> A qualified package name, from a textual language point of view,
> seems a better way to identify a package than an nsURI; the latter is
> more XML centric than human centric.
Yes, and more natural to map to Java.
> We want the textual notation to be capable of completely
> specifying everything that's needed for the GenModel.
You mean needed for a minimal/default GenModel, not every feature of a
GenModel?
> An Xcore resource contains the XPackage syntactically,
> but semantically an EPackage, a GenModel/GenPackage, and a
> Jvm Types model are induced each from the previous layer; those are
> contained as tertiary derived objects in the root of the resource.
Yes, I looked at the source and saw how they were added. If I understand
this correctly, you need the genmodel to correctly map to JvmTypes and
JvmTypes to support Xbase and interoperate with Java. Right?
> It's very easy to induce an Xcore resource from Ecore, so I expect
> Xcore to be interesting as an API primarily when you want control
> over behavioral details.
I can think of two more reasons:
- the Xcore model/API may be more convenient
- Xcore's tooling may be more convenient (e.g. more powerful and easier
to integrate into you own tool)
> I really don't like the idea of allowing classes to nest.
> We'd like to avoid allowing packages to nest even. This type of
> syntactic sugar often turns into a form of semantic rat poison.
> Nested packages have caused no end of trouble over the years while
> contributing pretty much nothing of value.
Xcore can provide value in many ways:
- extend Ecore with behavior, by integrating Xbase
- support textual editing with all the nice editor features we all love,
like completion, navigation, quick fixes etc.
- provide a more convenient/comprehensible model/syntax than Ecore,
without changing or adding semantics (and perhaps leave out
inconvenient/incomprehensible Ecore features like nested packages)
- provide tools that make prototyping quicker and improve
interoperability with Java
An example of convenience/comprehensible syntax is how +,?,* and
lower..upper is used for multiplicity. The motivation for inlining
classes (more appropriate term than nesting) is convenience (third
bullet) (and comprehension, since the containment structure will be
easier to read from the source). It does not add or change semantics.
The problem with nested packages, on the other hand, is that the
semantics is confusing.
In a discussion about desirable Xcore features, it can perhaps be useful
to structure wishes/requirements under headlines like the bullets above.
Another convenience could be to refer directly to a Java class in an
attribute definition, and get an auto-generated EDataType.
Hallvard
|
|
|
| Re: [xcore] A textual language for Ecore [message #714162 is a reply to message #714158] |
Tue, 09 August 2011 23:56 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 09/08/2011 4:02 PM, Hallvard Trætteberg wrote:
> Continuing the thread from the blog post:
>
> > A qualified package name, from a textual language point of view,
> > seems a better way to identify a package than an nsURI; the latter
> is > more XML centric than human centric.
>
> Yes, and more natural to map to Java.
>
> > We want the textual notation to be capable of completely
> > specifying everything that's needed for the GenModel.
>
> You mean needed for a minimal/default GenModel, not every feature of a
> GenModel?
At this point we're already mapping (automatically/reflectively) in both
directions all single-valued attributes of the whole deal.
>
> > An Xcore resource contains the XPackage syntactically,
> > but semantically an EPackage, a GenModel/GenPackage, and a
> > Jvm Types model are induced each from the previous layer; those are
> > contained as tertiary derived objects in the root of the resource.
>
> Yes, I looked at the source and saw how they were added. If I
> understand this correctly, you need the genmodel to correctly map to
> JvmTypes and JvmTypes to support Xbase and interoperate with Java. Right?
Yes. The GenModel ultimately has all the smarts for how exactly things
map onto Java.
>
> > It's very easy to induce an Xcore resource from Ecore, so I expect
> > Xcore to be interesting as an API primarily when you want control
> > over behavioral details.
>
> I can think of two more reasons:
> - the Xcore model/API may be more convenient
No, I think it will be more complex.
> - Xcore's tooling may be more convenient (e.g. more powerful and
> easier to integrate into you own tool)
Yes, I think it will be more expressive and powerful...
>
> > I really don't like the idea of allowing classes to nest.
> > We'd like to avoid allowing packages to nest even. This type of
> > syntactic sugar often turns into a form of semantic rat poison.
> > Nested packages have caused no end of trouble over the years while
> > contributing pretty much nothing of value.
>
> Xcore can provide value in many ways:
> - extend Ecore with behavior, by integrating Xbase
> - support textual editing with all the nice editor features we all
> love, like completion, navigation, quick fixes etc.
> - provide a more convenient/comprehensible model/syntax than Ecore,
> without changing or adding semantics (and perhaps leave out
> inconvenient/incomprehensible Ecore features like nested packages)
> - provide tools that make prototyping quicker and improve
> interoperability with Java
Yes, definitely all these things.
>
> An example of convenience/comprehensible syntax is how +,?,* and
> lower..upper is used for multiplicity.
Yes.
> The motivation for inlining classes (more appropriate term than
> nesting) is convenience (third bullet) (and comprehension, since the
> containment structure will be easier to read from the source). It does
> not add or change semantics.
And then it turns out you do want to use the class somewhere else after
all and you have yet another kind of refactoring...
> The problem with nested packages, on the other hand, is that the
> semantics is confusing.
They're nonexistent.
>
> In a discussion about desirable Xcore features, it can perhaps be
> useful to structure wishes/requirements under headlines like the
> bullets above.
Yes, we'll need to be more organized...
>
> Another convenience could be to refer directly to a Java class in an
> attribute definition, and get an auto-generated EDataType.
We've added support for synonyms (you can use the Java name) for Ecore's
built-in types. How far to go with that...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [xcore] A textual language for Ecore [message #714265 is a reply to message #714162] |
Wed, 10 August 2011 07:26 |
| Eclipse User |
|
|
|
Originally posted by:
On 10.08.11 01.56, Ed Merks wrote:
>>
>> I can think of two more reasons:
>> - the Xcore model/API may be more convenient
> No, I think it will be more complex.
If Xcore fits your own problem it can be more complex and be more
convenient. At least that's what I'm hoping ;-)
>> The motivation for inlining classes (more appropriate term than
>> nesting) is convenience (third bullet) (and comprehension, since the
>> containment structure will be easier to read from the source). It does
>> not add or change semantics.
> And then it turns out you do want to use the class somewhere else after
> all and you have yet another kind of refactoring...
You should be able to refer to an inlined class by name, as if it is was
defined non-inlined in the package. And you can move it if you want to.
>> Another convenience could be to refer directly to a Java class in an
>> attribute definition, and get an auto-generated EDataType.
> We've added support for synonyms (you can use the Java name) for Ecore's
> built-in types. How far to go with that...
A possibility is to alias every EDataType in the index with the name of
the wrapped class. So if you write java.net.URI you link to the
EDataType wrapping it, whatever name you chose. You may need to refer to
the EDataType name when there are several for the same java type. E.g. I
can imagine several EDataTypes wrapping String, with different
constraints on the String's content.
Hallvard
|
|
|
| Re: [xcore] A textual language for Ecore [message #714388 is a reply to message #714265] |
Wed, 10 August 2011 13:05 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 10/08/2011 12:26 AM, Hallvard Trætteberg wrote:
> On 10.08.11 01.56, Ed Merks wrote:
>>>
>>> I can think of two more reasons:
>>> - the Xcore model/API may be more convenient
>> No, I think it will be more complex.
>
> If Xcore fits your own problem it can be more complex and be more
> convenient. At least that's what I'm hoping ;-)
The extent to which the complexity is extra expressive power, that's a
good thing. The extent to which it's just there because of syntactic
sugar, it doesn't help. E.g., multiplicities are more complex in Xcore,
but not in a way that's helpful for writing logic against the API.
>
>>> The motivation for inlining classes (more appropriate term than
>>> nesting) is convenience (third bullet) (and comprehension, since the
>>> containment structure will be easier to read from the source). It does
>>> not add or change semantics.
>> And then it turns out you do want to use the class somewhere else after
>> all and you have yet another kind of refactoring...
>
> You should be able to refer to an inlined class by name, as if it is
> was defined non-inlined in the package. And you can move it if you
> want to.
The nesting has no significance whatsoever then. It's certainly
additional complexity yet it seems of minimally helpful as syntactic
sugar...
>
>>> Another convenience could be to refer directly to a Java class in an
>>> attribute definition, and get an auto-generated EDataType.
>> We've added support for synonyms (you can use the Java name) for Ecore's
>> built-in types. How far to go with that...
>
> A possibility is to alias every EDataType in the index with the name
> of the wrapped class.
Yes, assuming it's unique which will quite often be the case...
> So if you write java.net.URI you link to the EDataType wrapping it,
> whatever name you chose. You may need to refer to the EDataType name
> when there are several for the same java type. E.g. I can imagine
> several EDataTypes wrapping String, with different constraints on the
> String's content.
Exactly. Models derived from XML Schema simple type restrictions are
often like this.
On the flip side, one might assign them names like String and URI and
not need special rules.
A related issue is how EDataType names can be used in the operation
bodies, if they can be used at all there. They'd act like a synonym in
that case...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:39:17 GMT 2024
Powered by FUDForum. Page generated in 0.02043 seconds |
] 
Search
Help
Register
Login
Home
