Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [Xcore] "private" utility methods
[Xcore] "private" utility methods [message #1356986] Thu, 15 May 2014 10:00 Go to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 601
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
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
Re: [Xcore] "private" utility methods [message #1358204 is a reply to message #1357477] Thu, 15 May 2014 21:55 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 601
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
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
>
Re: [Xcore] "private" utility methods [message #1359109 is a reply to message #1358821] Fri, 16 May 2014 07:12 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 601
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
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
>
Previous Topic:GUI Helper of org.eclipse.emf.ecore.presentation
Next Topic:Run CDO Server in Web
Goto Forum:
  


Current Time: Thu Dec 18 00:55:56 GMT 2014

Powered by FUDForum. Page generated in 0.06604 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software