Status: New
Owner: ---- CC: [hidden email] Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.7 New issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 Consider this case: ---ACalssUsedAsArgumentType.java package packageDefiningArgumentType; public class ACalssUsedAsArgumentType { } ---UserClass.java package userPackage; import packageDefiningArgumentType.*; public class userClass { public void m() { new ArrayList<ACalssUsedAsArgumentType>();} } VerveineJ sets the container of the ParameterizedType to be userPackage.userClass.m(). This is wrong. The issue gets even worse when we have multiple users of the same type. For example, if we also get: ---SecondUserClass.java package secondUserPackage; import packageDefiningArgumentType.*; public class SecondUserClass { public void m() { new ArrayList<ACalssUsedAsArgumentType>();} } ... with the current setup, we will get only one ParameterizedType, but we do not know which container we will end up with (the first or the second method). To fix the situation we have two options: 1. Continue to have only one instance of ParameterizedType and have the container point to the container of the ParameterizableClass. 2. Have multiple instances for ParameterizedTypes and keep the rest as it is. I think I prefer 1. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Labels: -Milestone-4.7 Comment #1 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 At the moment, I have overriden FAMIXParameterizedType>>container to point to the container of the parameterizableClass. Still the exporter should be fixed, too. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Status: Accepted Comment #2 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 I tested with the two classes given as example. Strange things happened: 1) two identical ParameterizedTypes were created !?! 2) ArrayList as a long list of ancestors, many of them Parameterizable (List<>, AbstractList<>). VerveineJ creates parameterizedTypes for all parameterizable super classes. I am not sure whether this is the right behavior ? 3) the behavior mentioned appeared so I will think a bit about how to implement the solution proposed _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #3 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 Having the superclasses is actually a wanted behavior for any type that is defined within the code, and the ParameterizedType is a newly defined type. Do you agree to pursue the solution with having the container point to the one from the ParameterizableClass and to only have one instance of the ParameterizedType? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #4 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 that would be the easiest solution for me. Now what do we do with: public void someMethod() { ArrayList<String> var1; ArrayList<Integer> var2; Currently we ignore the parameter type, so there would be only one ParameterizedType ... ===//=== Another issue is with the super types: ArrayList<> inherits from AbstractList<> and implements List<> But the interface nature of List<> does not appear in the ParameterizedType List<> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #5 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 public void someMethod() { ArrayList<String> var1; ArrayList<Integer> var2; At the end, we should get two different ParameterizedTypes, based on the fully qualified name that should include the argument types, as well. And yes, it would be cool if List<> would be marked with isInterface. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #6 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 Maybe i missed it, but what happens with this: Map<String, Integer> map1; Map<Long, String> map1; _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #7 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 You should still get two distinct types. It is the qualified name (e.g., Map<String, Integer>) that should give you the indication. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #8 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 Now, if ArrayList<String> var1; ArrayList<Integer> var2; are two different ParameterizedType only because their attribute 'arguments' are different. Then wouldn't it make sense that 2 ArrayList<Something> in two different methods should also be different? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #9 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 It's not the same issue. 1) Having distinct instances for ArrayList<String> and ArrayList<Integer> allows me to reason about the specific types referenced throughout the system. I can then ask how many variables are there of these types. 2) Having multiple instances of an ArrayList<String> provides a different type of information, that is anyway provided by the associations Reference, Invocation or Access. All in all, we would benefit from 1), but not as much from 2). _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Status: Fixed Comment #10 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 implemented solution 1) _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Labels: Milestone-4.7 Comment #11 on issue 868 by [hidden email]: VerveineJ does not set the container of a ParameterizedType correctly http://code.google.com/p/moose-technology/issues/detail?id=868 Yuppee! Thanks _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |