| Xcore workaround for bug 89325??? [message #1695987] |
Wed, 20 May 2015 22:49  |
 Erick Hagstrom
Messages: 107
Registered: April 2014
Location: USA |
Senior Member |
|
|
Hey folks! *waves at Ed Merks*
One of my team members stumbled across bug number 89325 after wresting with the issue expressed therein. We see the workaround recommended for people who are using straight Ecore and are willing to modify their generated code. We are using Xcore and would really prefer to leave the generated code in the src-gen folder and treat it like, well, generated code. (Yes, we understand that there are configuration management wrinkles here, and we've made the informed choice that this is how we'd like to do things.)
So here we are in Xcore with noncontainment unidirectional references to EObjects that are contained elsewhere. Our use case looks very much like the popular method argument use case that seems to be accepted as legitimate. And we find ourselves stuck.
Problem #1: how do we even specify non-unique on the reference? There's a "unique" keyword, but the unique property is true whether "unique" is present or absent. We've tried doing a @Ecore annotation on the reference, but all we've found is multiple ways that doesn't work. So it doesn't seem like it's even possible to specify a non-unique refers in Xcore.
Problem #2: bug 89325 is still floating around. What's the best way to work around it now? Do we absolutely need to override the EObjectResolvingEList.isUnique() method in the generated code? Cuz, though we'd rather not, if that's the only way, well, "where there is clarity there is no choice, and where there is choice there is misery", eh?
|
|
|
| Re: Xcore workaround for bug 89325??? [message #1696007 is a reply to message #1695987] |
Thu, 21 May 2015 06:57  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Erick,
Comments below.
On 21/05/2015 12:49 AM, Erick Hagstrom wrote:
> Hey folks! *waves at Ed Merks*
>
> One of my team members stumbled across bug number 89325 after wresting
> with the issue expressed therein.
That horrible old thing...
> We see the workaround recommended for people who are using straight
> Ecore and are willing to modify their generated code. We are using
> Xcore and would really prefer to leave the generated code in the
> src-gen folder and treat it like, well, generated code. (Yes, we
> understand that there are configuration management wrinkles here, and
> we've made the informed choice that this is how we'd like to do things.)
>
> So here we are in Xcore with noncontainment unidirectional references
> to EObjects that are contained elsewhere. Our use case looks very much
> like the popular method argument use case that seems to be accepted as
> legitimate. And we find ourselves stuck.
:-(
>
> Problem #1: how do we even specify non-unique on the reference?
> There's a "unique" keyword, but the unique property is true whether
> "unique" is present or absent.
I see what you mean. I suppose that's semi-intentional, but isn't
really right given the grammar...
> We've tried doing a @Ecore annotation on the reference, but all we've
> found is multiple ways that doesn't work. So it doesn't seem like it's
> even possible to specify a non-unique refers in Xcore.
So you tried @Ecore(^unique="false") and noticed it threw exceptions
(trying to assign the string value to the boolean feature). That
should really be fixed. Please open a bugzilla if that helps...
>
> Problem #2: bug 89325 is still floating around. What's the best way to
> work around it now? Do we absolutely need to override the
> EObjectResolvingEList.isUnique() method in the generated code?
Yes, sorry...
> Cuz, though we'd rather not, if that's the only way, well, "where
> there is clarity there is no choice, and where there is choice there
> is misery", eh?
Indeed.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Xcore workaround for bug 89325??? [message #1696067 is a reply to message #1696007] |
Thu, 21 May 2015 13:26 |
Erick Hagstrom
Messages: 107
Registered: April 2014
Location: USA |
Senior Member |
|
|
Thanks, Ed. Opening the bugzilla on @Ecore(^unique="false"). (And yes, that's what we thought it ought to be, and yes, that's what happened when we tried it. The new bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=467855
We managed to find a workaround for bug 89325 itself.
First, we wrote an extension of EObjectResolvingEList that returned false in isUnique(). Then, wherever we needed it, we created an attribute of that List type and a getWhatever() method that does exactly what the generated code would otherwise do: create the List if it doesn't exist, then return it.
So now we have choice, and we're miserable. 
|
|
|
Powered by
FUDForum. Page generated in 0.03827 seconds
] 
Search
Help
Register
Login
Home
