Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology

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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue 868 in moose-technology: VerveineJ does not set the container of a ParameterizedType correctly

moose-technology
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