Home » Modeling » EMF » EMF Validation ?Bug? in EGenericTypeImpl(There may be a bug when validating References that use a Generic EClass including a binding of the generic type argument)
| EMF Validation ?Bug? in EGenericTypeImpl [message #1706645] |
Fri, 28 August 2015 11:58  |
 Lukas Baron
Messages: 17
Registered: June 2012 |
Junior Member |
|
|
Hello,
during (meta-) modeling some stuff, I came to a point, where the generic model editors included in EMF do not want to instanciate references that bind a generic type argument in their type.
This is complex stuff, so I'll try to explain the problem properly. Please refer to the picture I have attached below:
All is about using a generic composite pattern in the ecore (purple box). It consists of an AbstractCompositeClass with a GenericTypeArgument T extends InfoInterface. The two composite classes CompositeNode and CompositeLeaf extend AbstractCompositeClass by forwarding their own GenericParamters A and B to T. I refer to this as By-Inheritance-Binding. All way down, I want to have some Leafs in the Composite, that can instanciate InfoInterface objects, which can be set to either Info1 or Info2 through the Parameter B (and A and T).
That Composite Pattern will be used by the CompositeUser1, to create some Object Structure. This CompositeUser1 (green box) has a reference to the AbstractCompositeClass<T> and binds its GenericType to Info1. I refer to it as By-Reference-Binding. This way the composite<Info1> reference should contain either CompositeNode<Info1> or CompositeLeaf<Parameter1>.
(AbstractCompositeUser2 is a even more complex case - which is kind of the case that is relevant for me, but the problem is the same.)
When creating a dinamic instance of the Example Class or CompositeUser1, the Editor won't instanciate the reference composite<Info1>. For tracking down the problem, I generated the code. During Debugging, I noticed, that the childDescriptors are correctly collected (CompositeUserItemProvider.collectNewChildDescriptors(Collection<Object>, Object) line: 145). When validating the descriptors, the (EGenericTypeImpl.isInstance(Object) line: 730) somehow returns a false. That prevents the editors from creating the child objects.
By the way, when instanciating the respective references by hand within the .xmi, the model will be valid.
So what is the problem here? Am I thinking wrong? or is it an edge case, which has not been considered yet?
By the way, when removing the By-Inheritance-Bindings (<<bind T>> B / <<bind T>> A), the ecore model will throw some warnings, but the generic editor is working as expected (creating the correct composite pattern and instanciating Info1 objects works). Unfortunately the code generation does not work anymore - as expected, because of the invalid java generic type argument binding.
I attached the projects for modeling the .ecore (with a dynamic instance of the Example-Class, and the class diag), as well as the project for debugging and its workspace. Unfortunately the workspace for all the modeling projects exceeded the maximum file site.
I am looking forward for solving this. Thank you very much in advance for any help.
|
|
|
| EMF Validation ?Bug? in EGenericTypeImpl - 2 [message #1707394 is a reply to message #1706645] |
Fri, 04 September 2015 13:10  |
Lukas Baron
Messages: 17
Registered: June 2012 |
Junior Member |
|
|
I did one step further with my example from the first post. What I did not explain, was the blueish box in the picture. This is more what I am interested in concerning the modeling. This would be the way to share the generic composite structure, that was modeled in the purple box, across multiple Classes (CompositeUser2_1 and Composite_User2_2). The configuration of the composite (which classes shall be referenced in the composite leaf - the Info-Reference) can be done by reifying the AbstractCompositeUser2 with an appropriate type parameter, e.g. bind X to Info1.
The step further can be seen in the orange box in the picture below:
Now I want to restrict the bound-type InfoInterface, that is shared by all generic type parameters, to the SpecialInfo-Interface. The restriction can be meta-modeled by the class AbstractCompositeUser3 which forwards the type parameter X->InfoInterface as new Paramter Y->SpecialInfo.
When the generic editor for the dynamic instance of the class Example is trying to validate ChildDescriptors for the reference case2, the validation fails in EGenericTypeImpl:998. Here it was tested, whether the TypeParameter B can be bound to my SpecialInfo1 class. Which should be the case, since SpecialInfo1 inherits from SpecialInfo inherits from InfoInterface and B,A,T,X are bound to InfoInterface.
From my point of view, the validation should not fail, because CompositeUser3 binds Y to SpecialInfo1, AbstractCompositeUser3 binds X to Y, AbstractCompositeUser2 instanciates AbstractCompositeClass with T bound to X and finally AbstractComposuteClass<T->SpecialInfo1> is reifiable by CompositeLeaf<B->SpecialInfo1> or CompositeNode<A->SpecialInfo1>, because T is forwarded as A and B, respectively.
Is there any solution, that can be applied to this, e.g. modifying the validation mechanisms?
Cheers Lukad
|
|
|
| Re: EMF Validation ?Bug? in EGenericTypeImpl - 2 [message #1707483 is a reply to message #1707394] |
Sat, 05 September 2015 09:12 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Lukas,
Comments below.
On 04/09/2015 3:10 PM, Lukas Baron wrote:
> I did one step further with my example from the first post. What I did not explain, was the blueish box in the picture.
It's best not to assume that I will remember anything from a
previous/different thread...
> This is more what I am interested in concerning the modeling. This would be the way to share the generic composite structure, that was modeled in the purple box, across multiple Classes (CompositeUser2_1 and Composite_User2_2). The configuration of the composite (which classes shall be referenced in the composite leaf - the Info-Reference) can be done by reifying the AbstractCompositeUser2 with an appropriate type parameter, e.g. bind X to Info1.
>
> The step further can be seen in the orange box in the picture below:
>
>
> Now I want to restrict the bound-type InfoInterface, that is shared by all generic type parameters, to the SpecialInfo-Interface. The restriction can be meta-modeled by the class AbstractCompositeUser3 which forwards the type parameter X->InfoInterface as new Paramter Y->SpecialInfo.
>
> When the generic editor for the dynamic instance of the class Example is trying to validate ChildDescriptors for the reference case2, the validation fails in EGenericTypeImpl:998.
When exactly do this happen? How can I reproduce this? The Ecore model
you show validates without errors and the Example.xmi validates without
errors...
I have a feeling you're referring to the analog of the following:
CompositeUser3 cu3 =
Example2Factory.eINSTANCE.createCompositeUser3();
EList<AbstractCompositeClass<SpecialInfo1>> composite =
cu3.getComposite();
CompositeLeaf<SpecialInfo1> leaf1 =
Example2Factory.eINSTANCE.createCompositeLeaf();
composite.add(leaf1);
CompositeLeaf<?> leaf2 =
Example2Factory.eINSTANCE.createCompositeLeaf();
composite.add(leaf2);
Here the last line is an error. I think this is the same case as what
you're complaining about, assuming I understand what you mean. In
particular, note that there is no runtime information about the type
arguments used to instantiate a CompositeLeaf, so it's dynamically it's
always like the leaf2 case, i.e., the type is unknown and is assumed to
be incompatible.
> Here it was tested, whether the TypeParameter B can be bound to my SpecialInfo1 class. Which should be the case, since SpecialInfo1 inherits from SpecialInfo inherits from InfoInterface and B,A,T,X are bound to InfoInterface.
> From my point of view, the validation should not fail, because CompositeUser3 binds Y to SpecialInfo1, AbstractCompositeUser3 binds X to Y, AbstractCompositeUser2 instanciates AbstractCompositeClass with T bound to X and finally AbstractComposuteClass<T->SpecialInfo1> is reifiable by CompositeLeaf<B->SpecialInfo1> or CompositeNode<A->SpecialInfo1>, because T is forwarded as A and B, respectively.
Of course you realize that this is almost impossible to understand this
line of reasoning. But if I understand correctly, it's like leaf2
above, and there is never information available to make it like leaf1 above.
>
> Is there any solution, that can be applied to this, e.g. modifying the validation mechanisms?
Given I don't know how to reproduce the problem and this "minimum"
example is far too complex to understand just from a verbal description
I can't definitively say what's a bug and what isn't a bug. Sometimes
there are just limitations...
> Cheers Lukad
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF Validation ?Bug? in EGenericTypeImpl - 2 [message #1707566 is a reply to message #1707559] |
Mon, 07 September 2015 12:30 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Lukas,
Comments below.
On 07/09/2015 1:13 PM, Lukas Baron wrote:
> Ok, sry for the complex matter. I'll try it again, easier:
>
> Please refer to the class diagram, that I have attached to this post:
But now it's a new diagram and the hour I spent figuring out what you
meant the last time is just thrown away.
>
>
>
> I have modeled an abstract generic class with the parameter "T1" ("AbstractGeneric1<T1>").
> There are two other generic classes "Generic1_1<T1_1>" and "Generic1_2<T1_2>" that extend the abstract class and that are not abstract.
> Both inheriting classes forward the generic type parameter "T1" of the super class as their own type parameter "T1_1" and "T1_2" simply by binding "T1" to it (see picture "<<bind T1>> T1_1" / "<<bind T1>> T1_2").
>
> There is the class "ModelRoot", that has a containment reference to the abstract class.
> This reference binds the type parameter "T1" to "SomeOtherClass" (see picture: "someReference:AbstractGeneric1<T1 -> SomeOtherClass>").
>
> The Metamodel (.ecore) is valid. Now I want to create a "dynamic instance" of the "ModelRoot"-Class (.xmi).
> And here comes the problem: When I try do create objects for the "someReference", the generic model editor does not offer any child elements for that reference (see screenshot below).
> I expect it to offer me options to create new child element of type "Generic1_1<T1_1->SomeOtherClass>" or "Generic1_2<T1_2->SomeOtherClass>".
That's the problem. There's nothing dynamic that carries the "T1_1 ->
SomeOtherClass" information. There's only Generic1 and Generic2 and
what's passed as type arguments when the instances are created is unknown.
>
>
>
> Without any generic type argument, the editor would have offered me those options as valid substitutes for "AbstractGeneric1".
Without the reified type information for ModelRoot's genericReference
feature it would allow Generic1_1 and Generic1_2. But given some
arbitrary instance of Generic1_1 there's no way to know if it's actually
allows or not...
> Is it intended behaviour of the model editor or not?
Consider if you had ModelRootYetAnother EClass that had someReference
that was of type AbstractGenericType<YetSomeOtherClass> and it contains
some instances of Generic1_1 presumably Generic1_1<YetSomeOtherClass>.
It would not actually be valid to move that Generic1_1 instance be a
child of ModelRoot, but one could only know this by knowing that
Generic1_1 is contained by ModelRootYetAnother, therefore its type
paramter must have been valid and there can't be valid with respect to
ModelRoot. It's all painfully complicated and there are simply limits
on what can be expected of a dynamic editor that does not carry runtime
type argument information but rather must rely on reification.
> I would really appreciate if this feature could be added to the editor.
No doubt, and one could argue that the checking could be less
pessimistic, i.e., if the type arguments are unknown then assume it's
probably okay, rather than assume it's not okay. But it seems to me
there will always be dark corners such as the one I described above that
will still not be correct, i.e., where such an optimistic assume is
wrong and can be shown to be wrong because the containment reference's
reified type provides information to the contrary.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Validation ?Bug? in EGenericTypeImpl - 2 [message #1707578 is a reply to message #1707566] |
Mon, 07 September 2015 13:51 |
Lukas Baron
Messages: 17
Registered: June 2012 |
Junior Member |
|
|
Ed,
Comments below.
>> Ok, sry for the complex matter. I'll try it again, easier:
>>
>> Please refer to the class diagram, that I have attached to this post:
>But now it's a new diagram and the hour I spent figuring out what you
>meant the last time is just thrown away.
It is not thrown away, because it is the very same problem. Consider "AbstractGeneric1" as the same as "AbstractCompositeClass", both with non-abstract generic classes inheriting from that abstract. Sry, if the new diagram causes trouble.
>> I have modeled an abstract generic class with the parameter "T1" ("AbstractGeneric1<T1>").
>> There are two other generic classes "Generic1_1<T1_1>" and "Generic1_2<T1_2>" that extend the abstract class and that are not abstract.
>> Both inheriting classes forward the generic type parameter "T1" of the super class as their own type parameter "T1_1" and "T1_2" simply by binding "T1" to it (see picture "<<bind T1>> T1_1" / "<<bind T1>> T1_2").
>>
>> There is the class "ModelRoot", that has a containment reference to the abstract class.
>> This reference binds the type parameter "T1" to "SomeOtherClass" (see picture: "someReference:AbstractGeneric1<T1 -> SomeOtherClass>").
>>
>> The Metamodel (.ecore) is valid. Now I want to create a "dynamic instance" of the "ModelRoot"-Class (.xmi).
>> And here comes the problem: When I try do create objects for the "someReference", the generic model editor does not offer any child elements for that reference (see screenshot below).
>> I expect it to offer me options to create new child element of type "Generic1_1<T1_1->SomeOtherClass>" or "Generic1_2<T1_2->SomeOtherClass>".
>That's the problem. There's nothing dynamic that carries the "T1_1 ->
>SomeOtherClass" information. There's only Generic1 and Generic2 and
>what's passed as type arguments when the instances are created is unknown.
I don't understand, why there is nothing that carries the information. The binding "T1 -> SomeOtherClass" is stored in the "someReference". And furthermore, the SuperType-Relation of "Generic1_1" stores, that "T1" is forwarded as "T1_1". When collecting the ChildDescriptors for "someReference" the "Generic1_1" and Generic1_2" classes are returned from the metamodel without any doubt. Now, it is a matter of validating the cild-descriptors for "someReference", no? At that point, the actual type argument should be known. So at least the creation of such elements should be possible in this case? In the end it is a question of the model validation that is done within EGenericTypeImpl. If it does not support such validation mechanism, it cannot validate models, too, that have been created without a generic editor.
>> Without any generic type argument, the editor would have offered me those options as valid substitutes for "AbstractGeneric1".
>Without the reified type information for ModelRoot's genericReference feature it would allow Generic1_1 and Generic1_2. But given some arbitrary instance of Generic1_1 there's no way to know if it's actually allows or not...
> Is it intended behaviour of the model editor or not?
>> Is it intended behaviour of the model editor or not?
>Consider if you had ModelRootYetAnother EClass that had someReference that was of type AbstractGenericType<YetSomeOtherClass> and it contains some instances of Generic1_1 presumably eneric1_1<YetSomeOtherClass>. It would not actually be valid to move that Generic1_1 instance be a child of ModelRoot, but one could only know this by knowing that Generic1_1 is contained by ModelRootYetAnother, therefore its type paramter must have been valid and there can't be valid with respect to ModelRoot. It's all painfully complicated and there are simply limits on what can be expected of a dynamic editor that does not carry runtime type argument information but rather must rely on reification.
I modified the class diagram according to your description:
I do not understand, why this is a "dark corner". If you want to move the "Generic1_1<YetSomeOtherClass>" as "someReference"-Child of "ModelRoot", the editor knows the restriction of the new "someReference". Why can't it validate it against the structure that has been moved. In this case, if there is a "genericReference" that contains Objects, that are no descendants of "SomeOtherClass" or "SomeOtherClass" itself? If there is missing Information about the original instanciation of "Generic1_1" with "T1_1->YetSomeOtherClass" can't we just store that to "Generic1_1" as a dynamic Attribute, like the xsi:type-argument?
>> I would really appreciate if this feature could be added to the editor.
> No doubt, and one could argue that the checking could be less pessimistic, i.e., if the type arguments are unknown then assume it's probably okay, rather than assume it's not okay. But it seems to me there will always be dark corners such as the one I described above that will still not be correct, i.e., where such an optimistic assume is wrong and can be shown to be wrong because the containment reference's reified type provides information to the contrary.
Actually the current code base is not able to prove the model to be wrong. On the following screenshot, you can see, that I have added two "Generic1_1" objects, one with a "SomeOtherClass" sub feature, and one with a "YetSomeOtherClass" sub feature. The validation succeeded, but that should not have happened, since "YetSomeOtherClass" is not a valid substitute for "SomeOtherClass", that has been specified as the generic type argument.
[Updated on: Mon, 07 September 2015 13:53] Report message to a moderator |
|
|
Goto Forum:
Current Time: Tue Apr 23 14:48:56 GMT 2024
Powered by FUDForum. Page generated in 0.04547 seconds |
] 
Search
Help
Register
Login
Home
