Home » Modeling » EMF » Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070105
| Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070105 [message #415771] |
Sun, 06 January 2008 12:02  |
 Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi.
In But 212780 I detected the following comment from Ed Merks:
------- Comment #2 From Ed Merks 2007-12-23 14:08:11 -0400
...
It also seems not good for operations and parameters
to end up converting List<Something> into a multi-
valued feature since that will change the signature
so I added guards to do that only for structural
features.
First of all, I do not understand why this changes the signature. If
you choose the option "suppress EMF types" this keeps the signature
as far as I know.
Otherwise it changes from List to EList.
I would prefer a lot to have an additional option
"suppress many-valued parameters for Operations"
Which triggers the new behavior, and to keep the old behavior otherwise.
One would just guard the new behavior with a check whether this option
is set.
Having multi-valued features in EOperations puts them on the MOF
abstraction level, as you have it now, they remain on the Java
abstraction level.
Is there any change to have this changed back to how it was??
One could as well provide an option
"support many-valued parameters for Operations"
and have the old behavior only if this option is set.
I know that the comment was done on the 23rd, and now committed on the
5th. I am really sorry I did not come earlier.
It seems there are two directions right now:
- support many-valued parameters with generic type, and potentially
in the future extend the options for the kind of code generated
for many-valued features and many-valued parameters to collections,
sets, bags, maps (defining eKeys() for parameters...))
or
- restrict many-valued things to features.
I think before making such a decision, and changing things in one or the
other direction, one should imagine that EMF would contain an elaborated
way of doing a reflection-API for operations call.
This seems more useful, if parameters have types a la UML/MOF.
Another thing is extraction of models from code using EMF. I know this
reengineering scenario is not the main scenario. But everybody must
agree, that there are much more reengineering problems than new coding.
Maybe not within the Eclipse members, but within the vertical
industries. Loosing the information of multi-valued parameters would
be a loss for this scenario too.
Best, Philipp
|
|
|
| Re: Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070 [message #415772 is a reply to message #415771] |
Sun, 06 January 2008 13:16  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Philipp,
Comments below.
Philipp W. Kutter wrote:
> Hi.
> In But 212780 I detected the following comment from Ed Merks:
>
> ------- Comment #2 From Ed Merks 2007-12-23 14:08:11 -0400
> ...
>
> It also seems not good for operations and parameters
> to end up converting List<Something> into a multi-
> valued feature since that will change the signature
> so I added guards to do that only for structural
> features.
>
> First of all, I do not understand why this changes the signature. If
> you choose the option "suppress EMF types" this keeps the signature
> as far as I know.
That's true. But we don't generally know this, e.g., when creating the
GenModel for the first time.
>
> Otherwise it changes from List to EList.
Yep, that's the point.
>
> I would prefer a lot to have an additional option
> "suppress many-valued parameters for Operations"
Why?
>
> Which triggers the new behavior, and to keep the old behavior otherwise.
> One would just guard the new behavior with a check whether this option
> is set.
Why though?
>
> Having multi-valued features in EOperations puts them on the MOF
> abstraction level, as you have it now, they remain on the Java
> abstraction level.
What's the impact of that though? You can still achieve your specific
desired result with existing annotations that specify the type of the
item and many="true".
>
> Is there any change to have this changed back to how it was??
I would have though this would have little impact and didn't get any
comment from Dave or anyone else about it...
> One could as well provide an option
> "support many-valued parameters for Operations"
> and have the old behavior only if this option is set.
Isn't it sufficient that you could use type="X" many="true" if you want
to get a multi-valued feature that turns into a List because of EMF type
suppression?
>
> I know that the comment was done on the 23rd, and now committed on the
> 5th. I am really sorry I did not come earlier.
Yep, there was just silence including from other committers.
>
>
> It seems there are two directions right now:
>
> - support many-valued parameters with generic type, and potentially
> in the future extend the options for the kind of code generated
> for many-valued features and many-valued parameters to collections,
> sets, bags, maps (defining eKeys() for parameters...))
>
> or
>
> - restrict many-valued things to features.
I don't see things as either or to this extend. I think everything is
still possible and it's a question of the least surprising to the most
users...
>
>
> I think before making such a decision, and changing things in one or the
> other direction, one should imagine that EMF would contain an
> elaborated way of doing a reflection-API for operations call.
> This seems more useful, if parameters have types a la UML/MOF.
Probably you're assuming that there's no way to achieve the EMF type you
want because of this change, but that's not the case...
>
> Another thing is extraction of models from code using EMF. I know this
> reengineering scenario is not the main scenario. But everybody must
> agree, that there are much more reengineering problems than new
> coding. Maybe not within the Eclipse members, but within the vertical
> industries. Loosing the information of multi-valued parameters would
> be a loss for this scenario too.
If you still feel strongly about it, comment on the bugzilla and see
what Dave says. I've just assumed that silence was agreement...
>
> Best, Philipp
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070 [message #415777 is a reply to message #415772] |
Sun, 06 January 2008 13:45 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Comments inline.
>> ------- Comment #2 From Ed Merks 2007-12-23 14:08:11 -0400
>> ...
>>
>> It also seems not good for operations and parameters
>> to end up converting List<Something> into a multi-
>> valued feature since that will change the signature
>> so I added guards to do that only for structural
>> features.
>>
>> First of all, I do not understand why this changes the signature. If
>> you choose the option "suppress EMF types" this keeps the signature
>> as far as I know.
> That's true. But we don't generally know this, e.g., when creating the
> GenModel for the first time.
>>
>> Otherwise it changes from List to EList.
> Yep, that's the point.
But the same is true if you have a getter with List, and then it is
changed to EList. Why do you change it for Operations, but not for features?
>> I would prefer a lot to have an additional option
>> "suppress many-valued parameters for Operations"
>> Which triggers the new behavior, and to keep the old behavior otherwise.
> Why?
Because it would keep the old behavior, and those people who need to
avoid signature change for operations, but like to keep signature
changes for features can turn this option on, rather than the existing
"suppress EMF Types" the others who want the old behavior (like me)
could turn the option off.
>> Having multi-valued features in EOperations puts them on the MOF
>> abstraction level, as you have it now, they remain on the Java
>> abstraction level.
> What's the impact of that though? You can still achieve your specific
> desired result with existing annotations that specify the type of the
> item and many="true".
But our reengineering scenario does not work anymore. We did just set
"suppress EMF types" to true, and then we got the many="true" deduced
from the existing code. For List, it did not change anything in the
signature. Now this work no more.
>> Is there any change to have this changed back to how it was??
> I would have though this would have little impact and didn't get any
> comment from Dave or anyone else about it...
I understand its not high prio, and nobody dies if it remains as it is.
My point was rather, that detecting Collection arguments as many-value
is a great feature of EMF, we are loosing right now.
>> One could as well provide an option
>> "support many-valued parameters for Operations"
>> and have the old behavior only if this option is set.
> Isn't it sufficient that you could use type="X" many="true" if you want
> to get a multi-valued feature that turns into a List because of EMF type
> suppression?
With this option I only speak about parameters of operations. I just
loose the feature that by simply setting "@model" in the comment, I get
all parameters correctly detected as multi-valued or not.
>> I know that the comment was done on the 23rd, and now committed on the
>> 5th. I am really sorry I did not come earlier.
> Yep, there was just silence including from other committers.
XMas days where kind of strange days...
>> It seems there are two directions right now:
>>
>> - support many-valued parameters with generic type, and potentially
>> in the future extend the options for the kind of code generated
>> for many-valued features and many-valued parameters to collections,
>> sets, bags, maps (defining eKeys() for parameters...))
>>
>> or
>>
>> - restrict many-valued things to features.
> I don't see things as either or to this extend. I think everything is
> still possible and it's a question of the least surprising to the most
> users...
I ask for not changing the default behavior. There is for instance a guy
at Credit-Suisse who continues extracting EMF models from their legacy
code and maintains the EMF tags. He would get different models now.
>> I think before making such a decision, and changing things in one or the
>> other direction, one should imagine that EMF would contain an
>> elaborated way of doing a reflection-API for operations call.
>> This seems more useful, if parameters have types a la UML/MOF.
> Probably you're assuming that there's no way to achieve the EMF type you
> want because of this change, but that's not the case...
I agree, it is only a problem for the reengineering scenario.
>> Another thing is extraction of models from code using EMF. I know this
>> reengineering scenario is not the main scenario. But everybody must
>> agree, that there are much more reengineering problems than new
>> coding. Maybe not within the Eclipse members, but within the vertical
>> industries. Loosing the information of multi-valued parameters would
>> be a loss for this scenario too.
> If you still feel strongly about it, comment on the bugzilla and see
> what Dave says. I've just assumed that silence was agreement...
I'll extract part of what I wrote above and attach it there.
Thanks for the answer,
Philipp
>>
>> Best, Philipp
|
|
|
| Re: Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070 [message #415781 is a reply to message #415777] |
Sun, 06 January 2008 17:44 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Philipp,
Comments below.
Philipp W. Kutter wrote:
> Comments inline.
>
>>> ------- Comment #2 From Ed Merks 2007-12-23 14:08:11 -0400
>>> ...
>>>
>>> It also seems not good for operations and parameters
>>> to end up converting List<Something> into a multi-
>>> valued feature since that will change the signature
>>> so I added guards to do that only for structural
>>> features.
>>>
>>> First of all, I do not understand why this changes the signature. If
>>> you choose the option "suppress EMF types" this keeps the signature
>>> as far as I know.
>> That's true. But we don't generally know this, e.g., when creating
>> the GenModel for the first time.
>>>
>>> Otherwise it changes from List to EList.
>> Yep, that's the point.
>
> But the same is true if you have a getter with List, and then it is
> changed to EList. Why do you change it for Operations, but not for
> features?
Because for features it makes a huge difference to how it's serialized a
single value that's a list will not serialize the same as a multi-valued
feature, whereas for operations, the issue of serialization doesn't arise.
>
>
>>> I would prefer a lot to have an additional option
>>> "suppress many-valued parameters for Operations"
> >> Which triggers the new behavior, and to keep the old behavior
> otherwise.
>> Why?
> Because it would keep the old behavior, and those people who need to
> avoid signature change for operations, but like to keep signature
> changes for features can turn this option on, rather than the existing
> "suppress EMF Types" the others who want the old behavior (like me)
> could turn the option off.
Are you actually affected by this?
>
>>> Having multi-valued features in EOperations puts them on the MOF
>>> abstraction level, as you have it now, they remain on the Java
>>> abstraction level.
>> What's the impact of that though? You can still achieve your
>> specific desired result with existing annotations that specify the
>> type of the item and many="true".
>
> But our reengineering scenario does not work anymore. We did just set
> "suppress EMF types" to true, and then we got the many="true" deduced
> from the existing code. For List, it did not change anything in the
> signature. Now this work no more.
I see. Likely Dave will agree with you and then I'll reconsider...
>
>>> Is there any change to have this changed back to how it was??
>> I would have though this would have little impact and didn't get any
>> comment from Dave or anyone else about it...
> I understand its not high prio, and nobody dies if it remains as it is.
> My point was rather, that detecting Collection arguments as many-value
> is a great feature of EMF, we are loosing right now.
How could the issue has not come up for parameters but it has for
operations for you? Just coincidence?
>
>>> One could as well provide an option
>>> "support many-valued parameters for Operations"
>>> and have the old behavior only if this option is set.
>> Isn't it sufficient that you could use type="X" many="true" if you
>> want to get a multi-valued feature that turns into a List because of
>> EMF type suppression?
> With this option I only speak about parameters of operations. I just
> loose the feature that by simply setting "@model" in the comment, I get
> all parameters correctly detected as multi-valued or not.
For many people what would happen is the signature would change and they
likely would consider that not to be correct.
>
>>> I know that the comment was done on the 23rd, and now committed on
>>> the 5th. I am really sorry I did not come earlier.
>> Yep, there was just silence including from other committers.
> XMas days where kind of strange days...
I'm a big loser. Could you tell I've been on vacation for three weeks?
>
>>> It seems there are two directions right now:
>>>
>>> - support many-valued parameters with generic type, and potentially
>>> in the future extend the options for the kind of code generated
>>> for many-valued features and many-valued parameters to collections,
>>> sets, bags, maps (defining eKeys() for parameters...))
>>>
>>> or
>>>
>>> - restrict many-valued things to features.
>> I don't see things as either or to this extend. I think everything
>> is still possible and it's a question of the least surprising to the
>> most users...
> I ask for not changing the default behavior. There is for instance a
> guy at Credit-Suisse who continues extracting EMF models from their
> legacy code and maintains the EMF tags. He would get different models
> now.
I see. That's a good reason. I'll talk to Dave next week. This whole
issue of List handling has always been a bit odd. When we are reloading
a model we could know about suppressed and behave accordingly. And when
reflecting from a model with List instead EList would could set
suppressed automatically. But all improvements risk affecting someone
in a way they don't like. :-(
>
>>> I think before making such a decision, and changing things in one or
>>> the
>>> other direction, one should imagine that EMF would contain an
>>> elaborated way of doing a reflection-API for operations call.
>>> This seems more useful, if parameters have types a la UML/MOF.
>> Probably you're assuming that there's no way to achieve the EMF type
>> you want because of this change, but that's not the case...
> I agree, it is only a problem for the reengineering scenario.
>
>
>>> Another thing is extraction of models from code using EMF. I know this
>>> reengineering scenario is not the main scenario. But everybody must
>>> agree, that there are much more reengineering problems than new
>>> coding. Maybe not within the Eclipse members, but within the
>>> vertical industries. Loosing the information of multi-valued
>>> parameters would
>>> be a loss for this scenario too.
>> If you still feel strongly about it, comment on the bugzilla and see
>> what Dave says. I've just assumed that silence was agreement...
> I'll extract part of what I wrote above and attach it there.
That's a good idea. We can continue the discussion so it's recorded for
others to find easily in the release notes...
>
> Thanks for the answer,
> Philipp
>>>
>>> Best, Philipp
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Operation parameters: List<Something> not treated as multi-valued any more since CVS 20070 [message #415792 is a reply to message #415781] |
Mon, 07 January 2008 12:23 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
>>>> Otherwise it changes from List to EList.
>>> Yep, that's the point.
>>
>> But the same is true if you have a getter with List, and then it is
>> changed to EList. Why do you change it for Operations, but not for
>> features?
> Because for features it makes a huge difference to how it's serialized a
> single value that's a list will not serialize the same as a multi-valued
> feature, whereas for operations, the issue of serialization doesn't arise.
Agree. But the issue with changing the signature is keeping signature of
legacy code, not serialization. And from the point of view of changing
code or not, both are equally bad or good.
And there is already an option which allows to avoid changing signature
at all, its the "Suppress EMF Types". (of course, this is only half
true, since EMF will change Collection into List. There is a feature
request pending asking to improve this)
>>>> I would prefer a lot to have an additional option
>>>> "suppress many-valued parameters for Operations"
>> >> Which triggers the new behavior, and to keep the old behavior
>> otherwise.
>>> Why?
>> Because it would keep the old behavior, and those people who need to
>> avoid signature change for operations, but like to keep signature
>> changes for features can turn this option on, rather than the existing
>> "suppress EMF Types" the others who want the old behavior (like me)
>> could turn the option off.
> Are you actually affected by this?
My colleagues at Credit Suisse who are continuing to reenginere code
with EMF would be affected. Every body who wants to get the UML version
of their Operation signatures (featuring multi-valued parameters) would
be affected.
Unfortunately, people in the various EMF based Eclipse framework do not
create EMF Models of their own code. If they would, and if they would
use the resulting docu where multi-valued features and parmameters show
the real type, not just List, all of them would be affected.
>>>> Having multi-valued features in EOperations puts them on the MOF
>>>> abstraction level, as you have it now, they remain on the Java
>>>> abstraction level.
>>> What's the impact of that though? You can still achieve your
>>> specific desired result with existing annotations that specify the
>>> type of the item and many="true".
>>
>> But our reengineering scenario does not work anymore. We did just set
>> "suppress EMF types" to true, and then we got the many="true" deduced
>> from the existing code. For List, it did not change anything in the
>> signature. Now this work no more.
> I see. Likely Dave will agree with you and then I'll reconsider...
I'll add this to the bug as comment... ;-)
>>>> Is there any change to have this changed back to how it was??
>>> I would have though this would have little impact and didn't get any
>>> comment from Dave or anyone else about it...
>> I understand its not high prio, and nobody dies if it remains as it is.
>> My point was rather, that detecting Collection arguments as many-value
>> is a great feature of EMF, we are loosing right now.
> How could the issue has not come up for parameters but it has for
> operations for you? Just coincidence?
For me this was never an issue but a greate feature of EMF. When I have
seen that something moves in the opposite direction, I became concerned.
>>>> One could as well provide an option
>>>> "support many-valued parameters for Operations"
>>>> and have the old behavior only if this option is set.
>>> Isn't it sufficient that you could use type="X" many="true" if you
>>> want to get a multi-valued feature that turns into a List because of
>>> EMF type suppression?
>> With this option I only speak about parameters of operations. I just
>> loose the feature that by simply setting "@model" in the comment, I get
>> all parameters correctly detected as multi-valued or not.
> For many people what would happen is the signature would change and they
> likely would consider that not to be correct.
I agree. Therefore its good enough to have an option to turn off the new
behavior.
But if you are consequent about what you say, you would ad wll turn
"suppress EMF Types" on by default, since if for someone its wrong to
change the signature of his Operation stuff from List to EList, then its
likely as well wrong to change the signature of his setters and getters
from List to EList.
>>>> I know that the comment was done on the 23rd, and now committed on
>>>> the 5th. I am really sorry I did not come earlier.
>>> Yep, there was just silence including from other committers.
>> XMas days where kind of strange days...
> I'm a big loser. Could you tell I've been on vacation for three weeks?
No way. Or did you take the laptop to Thaiti?
>> I ask for not changing the default behavior. There is for instance a
>> guy at Credit-Suisse who continues extracting EMF models from their
>> legacy code and maintains the EMF tags. He would get different models
>> now.
> I see. That's a good reason. I'll talk to Dave next week. This whole
> issue of List handling has always been a bit odd. When we are reloading
> a model we could know about suppressed and behave accordingly. And when
> reflecting from a model with List instead EList would could set
> suppressed automatically. But all improvements risk affecting someone
> in a way they don't like. :-(
But with well documented options, the old behavior can be kept and the
new features are just default for new projects.
I think handling multi-valued features and parameters as such is one of
the big strength of EMF. Its as well the unique feature, which should
people drive to document their code with EMF, and not a standard UML
tool. The standard tools cannot create correct references and
parameters, they just create stupid getter and setter signatures, full
of list and collection.
My vision is that the treatment of many-valued features and parameters
is refined in the future, such that setting options like "ordered" and
"unique" and "eKeys()" one can direct EMF in a fine tuned way to
generate the right implementation as list, collection, set, bag, or map.
OCL is then well prepared to deal with collection, set, bag, list.
Best, Philipp
Best Regards,
Philipp
|
|
|
Goto Forum:
Current Time: Fri Apr 26 21:19:54 GMT 2024
Powered by FUDForum. Page generated in 0.02946 seconds |
] 
Search
Help
Register
Login
Home
