Home » Modeling » EMF » [xcore] Implement method outside of xcore model
| [xcore] Implement method outside of xcore model [message #1237848] |
Thu, 30 January 2014 19:16  |
 Phillip Keldenich
Messages: 9
Registered: January 2014 |
Junior Member |
|
|
Hey,
we are using xcore to describe some kind of hierarchical automaton model.
For some operations, this model has to be "flattened" to fit into an internal datastructure that is not part of an xcore model.
There are no problems on that part; but the flattening operation itself has to use several recursive helper methods and is rather complicated/long and as the model itself contains relatively many classes, it is really ugly to implement the method inside the .xcore file.
Moreover, this would make the recursive helper methods public (and they really should not be). Is there a way to create private ops in xcore?
The flattening method also does not access any internals of the hierarchical model; it merely uses the public interface, so it can easily be implemented outside of the model (for example as a static method in some uninstantiable implementation class that is then called by the operation in the .xcore file).
However, this approach leads to the following problem:
The static method needs to take parameters and return values that are instances of some generated interface. This means that the methods signature contains compile-time errors in absence of the generated code.
This in turn introduces errors in the body of the flattening operation definition in the .xcore model as a non-existing/erroneous method is called; this in turn completely stops the code generation, creating a cycle that can be broken by commenting out the body of the operation in the .xcore file, waiting for code generation to run, and then uncommenting the body.
It would be really nice if xcore was more "graceful" in the sense that errors in some op body did not lead to a full stop of the generation.
Suppose one does not want to remove the flattening operation (it really is just one example for this problem) and put it into a completely external class: What is the way to go? How does one elegantly implement complex methods that are part of the interface of some class in an xcore model outside of the .xcore file?
I have searched through the (rather short) xcore documentation, but I could not find a reasonably nice solution there.
|
|
|
| Re: [xcore] Implement method outside of xcore model [message #1240962 is a reply to message #1237848] |
Fri, 07 February 2014 09:18  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Phillip,
Comments below.
On 30/01/2014 10:17 PM, Phillip Keldenich wrote:
> Hey,
>
> we are using xcore to describe some kind of hierarchical automaton model.
> For some operations, this model has to be "flattened" to fit into an
> internal datastructure that is not part of an xcore model.
> There are no problems on that part; but the flattening operation
> itself has to use several recursive helper methods and is rather
> complicated/long and as the model itself contains relatively many
> classes, it is really ugly to implement the method inside the .xcore
> file.
I see.
> Moreover, this would make the recursive helper methods public (and
> they really should not be). Is there a way to create private ops in
> xcore?
Not a very nice way, but via an Ecore annotation (as produced by
org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EStructuralFeature,
int, boolean)) you can suppress them from the public API...
> The flattening method also does not access any internals of the
> hierarchical model; it merely uses the public interface, so it can
> easily be implemented outside of the model (for example as a static
> method in some uninstantiable implementation class that is then called
> by the operation in the .xcore file).
Yes, a static utility method...
> However, this approach leads to the following problem:
> The static method needs to take parameters and return values that are
> instances of some generated interface. This means that the methods
> signature contains compile-time errors in absence of the generated code.
Yes, but it's normal that you should write Java code that depends on
generated code... Not sure how this is a problem...
> This in turn introduces errors in the body of the flattening operation
> definition in the .xcore model as a non-existing/erroneous method is
> called; this in turn completely stops the code generation, creating a
> cycle that can be broken by commenting out the body of the operation
> in the .xcore file, waiting for code generation to run, and then
> uncommenting the body.
Hmmm. Is this the case using the latest version of Xcore? This type of
scenario should work. Xtext's generator framework helps produce "stubs"
for the generated interfaces as part of the working copy being used by
hand written code, so that signatures can be compiled....
> It would be really nice if xcore was more "graceful" in the sense that
> errors in some op body did not lead to a full stop of the generation.
>
> Suppose one does not want to remove the flattening operation (it
> really is just one example for this problem) and put it into a
> completely external class: What is the way to go? How does one
> elegantly implement complex methods that are part of the interface of
> some class in an xcore model outside of the .xcore file?
Can you create a small test case illustrating the nature of the problem
and open a bugzilla so I can investigate what's going wrong. What you
describe (external utility method that relies on generated interfaces)
should work...
> I have searched through the (rather short) xcore documentation, but I
> could not find a reasonably nice solution there.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [xcore] Implement method outside of xcore model [message #1244140 is a reply to message #1240962] |
Wed, 12 February 2014 00:12 |
Phillip Keldenich
Messages: 9
Registered: January 2014 |
Junior Member |
|
|
Am 07.02.2014 10:18, schrieb Ed Merks:
> Phillip,
>
> Comments below.
>
> On 30/01/2014 10:17 PM, Phillip Keldenich wrote:
>> Hey,
>>
>> we are using xcore to describe some kind of hierarchical automaton model.
>> For some operations, this model has to be "flattened" to fit into an
>> internal datastructure that is not part of an xcore model.
>> There are no problems on that part; but the flattening operation
>> itself has to use several recursive helper methods and is rather
>> complicated/long and as the model itself contains relatively many
>> classes, it is really ugly to implement the method inside the .xcore
>> file.
> I see.
>> Moreover, this would make the recursive helper methods public (and
>> they really should not be). Is there a way to create private ops in
>> xcore?
> Not a very nice way, but via an Ecore annotation (as produced by
> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EStructuralFeature,
> int, boolean)) you can suppress them from the public API...
>> The flattening method also does not access any internals of the
>> hierarchical model; it merely uses the public interface, so it can
>> easily be implemented outside of the model (for example as a static
>> method in some uninstantiable implementation class that is then called
>> by the operation in the .xcore file).
> Yes, a static utility method...
>> However, this approach leads to the following problem:
>> The static method needs to take parameters and return values that are
>> instances of some generated interface. This means that the methods
>> signature contains compile-time errors in absence of the generated code.
> Yes, but it's normal that you should write Java code that depends on
> generated code... Not sure how this is a problem...
>> This in turn introduces errors in the body of the flattening operation
>> definition in the .xcore model as a non-existing/erroneous method is
>> called; this in turn completely stops the code generation, creating a
>> cycle that can be broken by commenting out the body of the operation
>> in the .xcore file, waiting for code generation to run, and then
>> uncommenting the body.
> Hmmm. Is this the case using the latest version of Xcore? This type of
> scenario should work. Xtext's generator framework helps produce "stubs"
> for the generated interfaces as part of the working copy being used by
> hand written code, so that signatures can be compiled....
>> It would be really nice if xcore was more "graceful" in the sense that
>> errors in some op body did not lead to a full stop of the generation.
>>
>> Suppose one does not want to remove the flattening operation (it
>> really is just one example for this problem) and put it into a
>> completely external class: What is the way to go? How does one
>> elegantly implement complex methods that are part of the interface of
>> some class in an xcore model outside of the .xcore file?
> Can you create a small test case illustrating the nature of the problem
> and open a bugzilla so I can investigate what's going wrong. What you
> describe (external utility method that relies on generated interfaces)
> should work...
>> I have searched through the (rather short) xcore documentation, but I
>> could not find a reasonably nice solution there.
>
Thanks for your reply.
I believe that I use the latest xcore version (at least looking for
updates in eclipse kepler does not yield anything).
The kindof minimal test setup that reproduces this error (for me) is the
following:
<<<file test.xcore>>>
package test
//type TestMethodImpl wraps TestMethodImpl - does not matter
class Test {
op Test testMethod(Test test) {
return TestMethodImpl.testMethodImpl(this);
}
}
<<</test.xcore>>>
<<<file TestMethodImpl.java>>>
package test;
public enum TestMethodImpl {;
static Test testMethodImpl(Test test) {
return test;
}
}
<<</TestMethodImpl.java>>>
Except for these two files, the project is empty and exactly as setup by
eclipse when creating a new xcore project.
My platform (though it should not matter) is linux x86_64, but I have
also encountered this problem on other platforms (including windows).
This works if one comments out the body of the testMethod op in the
xcore file, waits for code generation to be complete, and then
uncomments the line again.
Cheers,
Phillip
|
|
|
| Re: [xcore] Implement method outside of xcore model [message #1244325 is a reply to message #1244140] |
Wed, 12 February 2014 07:04 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Phillip,
Comments below.
On 12/02/2014 1:12 AM, Phillip Keldenich wrote:
> Am 07.02.2014 10:18, schrieb Ed Merks:
>> Phillip,
>>
>> Comments below.
>>
>> On 30/01/2014 10:17 PM, Phillip Keldenich wrote:
>>> Hey,
>>>
>>> we are using xcore to describe some kind of hierarchical automaton model.
>>> For some operations, this model has to be "flattened" to fit into an
>>> internal datastructure that is not part of an xcore model.
>>> There are no problems on that part; but the flattening operation
>>> itself has to use several recursive helper methods and is rather
>>> complicated/long and as the model itself contains relatively many
>>> classes, it is really ugly to implement the method inside the .xcore
>>> file.
>> I see.
>>> Moreover, this would make the recursive helper methods public (and
>>> they really should not be). Is there a way to create private ops in
>>> xcore?
>> Not a very nice way, but via an Ecore annotation (as produced by
>> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EStructuralFeature,
>> int, boolean)) you can suppress them from the public API...
>>> The flattening method also does not access any internals of the
>>> hierarchical model; it merely uses the public interface, so it can
>>> easily be implemented outside of the model (for example as a static
>>> method in some uninstantiable implementation class that is then called
>>> by the operation in the .xcore file).
>> Yes, a static utility method...
>>> However, this approach leads to the following problem:
>>> The static method needs to take parameters and return values that are
>>> instances of some generated interface. This means that the methods
>>> signature contains compile-time errors in absence of the generated code.
>> Yes, but it's normal that you should write Java code that depends on
>> generated code... Not sure how this is a problem...
>>> This in turn introduces errors in the body of the flattening operation
>>> definition in the .xcore model as a non-existing/erroneous method is
>>> called; this in turn completely stops the code generation, creating a
>>> cycle that can be broken by commenting out the body of the operation
>>> in the .xcore file, waiting for code generation to run, and then
>>> uncommenting the body.
>> Hmmm. Is this the case using the latest version of Xcore? This type of
>> scenario should work. Xtext's generator framework helps produce "stubs"
>> for the generated interfaces as part of the working copy being used by
>> hand written code, so that signatures can be compiled....
>>> It would be really nice if xcore was more "graceful" in the sense that
>>> errors in some op body did not lead to a full stop of the generation.
>>>
>>> Suppose one does not want to remove the flattening operation (it
>>> really is just one example for this problem) and put it into a
>>> completely external class: What is the way to go? How does one
>>> elegantly implement complex methods that are part of the interface of
>>> some class in an xcore model outside of the .xcore file?
>> Can you create a small test case illustrating the nature of the problem
>> and open a bugzilla so I can investigate what's going wrong. What you
>> describe (external utility method that relies on generated interfaces)
>> should work...
>>> I have searched through the (rather short) xcore documentation, but I
>>> could not find a reasonably nice solution there.
> Thanks for your reply.
> I believe that I use the latest xcore version (at least looking for
> updates in eclipse kepler does not yield anything).
The latest is the is for the Luna stream.
> The kindof minimal test setup that reproduces this error (for me) is the
> following:
>
> <<<file test.xcore>>>
> package test
>
> //type TestMethodImpl wraps TestMethodImpl - does not matter
>
> class Test {
> op Test testMethod(Test test) {
> return TestMethodImpl.testMethodImpl(this);
> }
> }
> <<</test.xcore>>>
>
> <<<file TestMethodImpl.java>>>
> package test;
>
> public enum TestMethodImpl {;
> static Test testMethodImpl(Test test) {
> return test;
> }
> }
> <<</TestMethodImpl.java>>>
This works for me, but a clean build of the project results in errors
that only go away if I comment out the body of the testMethod and
uncomment it again, so something isn't still quite right...
>
> Except for these two files, the project is empty and exactly as setup by
> eclipse when creating a new xcore project.
> My platform (though it should not matter) is linux x86_64, but I have
> also encountered this problem on other platforms (including windows).
> This works if one comments out the body of the testMethod op in the
> xcore file, waits for code generation to be complete, and then
> uncomments the line again.
Yes, exactly. But that shouldn't be necessary. Please open a bugzilla
with this simple example and I'll investigate further...
>
> Cheers,
> Phillip
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:55:22 GMT 2024
Powered by FUDForum. Page generated in 0.03180 seconds |
] 
Search
Help
Register
Login
Home
