Home » Modeling » EMF » [Xcore] "private" utility methods
[Xcore] "private" utility methods [message #1356986] |
Thu, 15 May 2014 10:00 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
I'm using Xcore for the first time, and would like advice on how to
structure my code. Usually, I have a mix of methods that are modeled
(i.e. operations) and private helper methods used by the modeled
operations' implementation. The former are part of the API, while the
latter aren't. However, since Xcode supports operation implementations
(bodies using Xbase) it seems easier and more natural to include the
helper methods in the xcore file, too. But then they become part of the
API, which is not what I want.
So the question is: is there a way of indicating that an implemented
operation should just be an ordinary (and private) method and not a
"real" operation.
My experience so far with Xcore is mixed: the language really boosts
productivity, but the builder seems to get confused and get stuck when
there are "complex" dependencies across files that break, e.g. due to
renaming. And when stuck I have to force quit and restart, and that
certainly lowers the productivity so much that I'm not sure I'll stick
with Xcore or go back to Ecore.
Hallvard
|
|
|
Re: [Xcore] "private" utility methods [message #1357477 is a reply to message #1356986] |
Thu, 15 May 2014 14:43 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 15/05/2014 12:00 PM, Hallvard Trætteberg wrote:
> I'm using Xcore for the first time, and would like advice on how to
> structure my code. Usually, I have a mix of methods that are modeled
> (i.e. operations) and private helper methods used by the modeled
> operations' implementation. The former are part of the API, while the
> latter aren't. However, since Xcode supports operation implementations
> (bodies using Xbase) it seems easier and more natural to include the
> helper methods in the xcore file, too. But then they become part of
> the API, which is not what I want.
In Xcore there isn't a way to declare something that's just a field or a
method in the implementation, so yes, at least reflectively, all such
modeled things are in the API
>
> So the question is: is there a way of indicating that an implemented
> operation should just be an ordinary (and private) method and not a
> "real" operation.
No. But of course you can suppress them from the public API using
@Ecore annotations, like the ones produced by
EcoreUtil.setSuppressedVisibility(EStructuralFeature, int, boolean) and
EcoreUtil.setSuppressedVisibility(EOperation, boolean).
>
> My experience so far with Xcore is mixed: the language really boosts
> productivity, but the builder seems to get confused and get stuck when
> there are "complex" dependencies across files that break, e.g. due to
> renaming.
Xcore supports refactoring, which also does the underlying Java
refactoring... Is this what you're using? I know from experience at
EclipseCon that the Canadian Space Agency is using Xcore extensively
with a large number of large Xcore models. They had a problem that we
debugged together to fix it...
> And when stuck I have to force quit and restart,
The IDE you mean?
> and that certainly lowers the productivity so much that I'm not sure
> I'll stick with Xcore or go back to Ecore.
I'm always happy to fix problems I can reproduce locally...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [Xcore] "private" utility methods [message #1358204 is a reply to message #1357477] |
Thu, 15 May 2014 21:55 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
On 15.05.14 16:43, Ed Merks wrote:
>
> In Xcore there isn't a way to declare something that's just a field or a
> method in the implementation, so yes, at least reflectively, all such
> modeled things are in the API
It's perhaps contrary to Xcore as a modeling language, but I think it
would certainly be useful to support plain private/protected methods and
fields that are generated into the implementation class, and hence are
only visible in that class (and subclasses, if protected is used). It
shouldn't be difficult to add...
>> So the question is: is there a way of indicating that an implemented
>> operation should just be an ordinary (and private) method and not a
>> "real" operation.
> No. But of course you can suppress them from the public API using
> @Ecore annotations, like the ones produced by
> EcoreUtil.setSuppressedVisibility(EStructuralFeature, int, boolean) and
> EcoreUtil.setSuppressedVisibility(EOperation, boolean).
This annotation has the opposite effect of what I need: The operation
still is modeled (which I don't want), but now it cannot be called in
operation bodies (which I want), since bodies are resolved against the
derived Java model, not the Ecore model.
> Xcore supports refactoring, which also does the underlying Java
> refactoring... Is this what you're using?
No, perhaps I should...
>> And when stuck I have to force quit and restart,
> The IDE you mean?
Yes!
>> and that certainly lowers the productivity so much that I'm not sure
>> I'll stick with Xcore or go back to Ecore.
> I'm always happy to fix problems I can reproduce locally...
My impression is that this is a memory issue, and that you have to be
careful to give Eclipse enough memory, based on experience with the
specific models you have and the kind of (disruptive) changes you do.
Small, incremental changes are handled very well, but bigger ones
triggers massive recalculations. BTW, I don't think this is specific to
Xcore, I've noticed the same issue in my own Xtext+Xbase DSLs.
Hallvard
|
|
|
Re: [Xcore] "private" utility methods [message #1358821 is a reply to message #1358204] |
Fri, 16 May 2014 04:19 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 15/05/2014 11:55 PM, Hallvard Trætteberg wrote:
> On 15.05.14 16:43, Ed Merks wrote:
>>
>> In Xcore there isn't a way to declare something that's just a field or a
>> method in the implementation, so yes, at least reflectively, all such
>> modeled things are in the API
>
> It's perhaps contrary to Xcore as a modeling language, but I think it
> would certainly be useful to support plain private/protected methods
> and fields that are generated into the implementation class, and hence
> are only visible in that class (and subclasses, if protected is used).
> It shouldn't be difficult to add...
Yes, I agree it would be very useful. There are definitely a few
challenges though. It does all need to feed into the standard generator
which is driven exclusively via Ecore/GenModel, but that shouldn't be
too difficult. It also would be nice to continue to support dynamic
instances, which seems more difficult...
>
>>> So the question is: is there a way of indicating that an implemented
>>> operation should just be an ordinary (and private) method and not a
>>> "real" operation.
>> No. But of course you can suppress them from the public API using
>> @Ecore annotations, like the ones produced by
>> EcoreUtil.setSuppressedVisibility(EStructuralFeature, int, boolean) and
>> EcoreUtil.setSuppressedVisibility(EOperation, boolean).
>
> This annotation has the opposite effect of what I need: The operation
> still is modeled (which I don't want), but now it cannot be called in
> operation bodies (which I want), since bodies are resolved against the
> derived Java model, not the Ecore model.
I see. I didn't consider that implication. This is another one of the
challenges. Because the inferred operation body can be used in many
implementation classes (because of support for multiple inheritance),
it's hard to infer a single one that serves this purpose.
>
>> Xcore supports refactoring, which also does the underlying Java
>> refactoring... Is this what you're using?
>
> No, perhaps I should...
Definitely, that's one of the significant advantages of Xcore. That a
single Xcore refactoring is the same as a dozen Java refactorings so
that all the hand written code that uses the generated API can be
refactored along with the API...
>
>>> And when stuck I have to force quit and restart,
>> The IDE you mean?
>
> Yes!
Perhaps like this one, which I wasn't able to reproduce:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=432072
>
>>> and that certainly lowers the productivity so much that I'm not sure
>>> I'll stick with Xcore or go back to Ecore.
>> I'm always happy to fix problems I can reproduce locally...
>
> My impression is that this is a memory issue, and that you have to be
> careful to give Eclipse enough memory, based on experience with the
> specific models you have and the kind of (disruptive) changes you do.
> Small, incremental changes are handled very well, but bigger ones
> triggers massive recalculations. BTW, I don't think this is specific
> to Xcore, I've noticed the same issue in my own Xtext+Xbase DSLs.
Certainly I've had cases where I didn't allocate enough memory and then
the VM tries so hard to do its work without enough memory that it
thrashes in the garbage collector seemingly forever before giving up
with an out of memory exception.
>
> Hallvard
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [Xcore] "private" utility methods [message #1359109 is a reply to message #1358821] |
Fri, 16 May 2014 07:12 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
On 16.05.14 06:19, Ed Merks wrote:
>>
>> It's perhaps contrary to Xcore as a modeling language, but I think it
>> would certainly be useful to support plain private/protected methods
>> and fields that are generated into the implementation class, and hence
>> are only visible in that class (and subclasses, if protected is used).
>> It shouldn't be difficult to add...
> Yes, I agree it would be very useful. There are definitely a few
> challenges though. It does all need to feed into the standard generator
> which is driven exclusively via Ecore/GenModel, but that shouldn't be
> too difficult. It also would be nice to continue to support dynamic
> instances, which seems more difficult...
Since this is about the generated implementation, it seems more correct
to add this to GenModel, rather than contaminating Ecore. Perhaps a
GenOperation could contain (i.e. not refer into the Ecore model) an
EOperation (to store the usual signature information and body
annotation) and generate only the implementation code. This way you
avoid affecting the Ecore model and can reuse all generation logic.
So from
impl op int foo(String bar) {
...
}
you derive nothing into the Ecore model, but a GenOperation containing
the EOperation you would normally derive if the impl keyword wasn't there.
Similar for EStructural features.
Hallvard
|
|
|
Re: [Xcore] "private" utility methods [message #1359385 is a reply to message #1359109] |
Fri, 16 May 2014 09:59 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 16/05/2014 9:12 AM, Hallvard Trætteberg wrote:
> On 16.05.14 06:19, Ed Merks wrote:
>>>
>>> It's perhaps contrary to Xcore as a modeling language, but I think it
>>> would certainly be useful to support plain private/protected methods
>>> and fields that are generated into the implementation class, and hence
>>> are only visible in that class (and subclasses, if protected is used).
>>> It shouldn't be difficult to add...
>> Yes, I agree it would be very useful. There are definitely a few
>> challenges though. It does all need to feed into the standard generator
>> which is driven exclusively via Ecore/GenModel, but that shouldn't be
>> too difficult. It also would be nice to continue to support dynamic
>> instances, which seems more difficult...
>
> Since this is about the generated implementation, it seems more
> correct to add this to GenModel, rather than contaminating Ecore.
> Perhaps a GenOperation could contain (i.e. not refer into the Ecore
> model) an EOperation (to store the usual signature information and
> body annotation) and generate only the implementation code. This way
> you avoid affecting the Ecore model and can reuse all generation logic.
That's interesting point, though anything not directly available in the
Ecore model is not available in a dynamic instance, so anything relying
on "real/simulated" fields or methods wouldn't work dynamically. I
suppose dynamic support is just a nice-to-have, but I'm a bit hung up
that...
>
> So from
>
> impl op int foo(String bar) {
> ...
> }
>
> you derive nothing into the Ecore model, but a GenOperation containing
> the EOperation you would normally derive if the impl keyword wasn't
> there.
>
It's an interesting idea to keep in mind to think about these things as
being like features and options, but hiding that fact from all the
normal (client visible) reflective APIs...
> Similar for EStructural features.
>
> Hallvard
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 17:42:23 GMT 2024
Powered by FUDForum. Page generated in 0.03075 seconds
|