Issue 999 in moose-technology: VerveineJ: management of the anonymous class

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-VerveineJ

New issue 999 by [hidden email]: VerveineJ: management of the  
anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

Describe the problem: what do you get? what do you expect?
According to the definition of
FAMIXType >>isAnonymousClass
        ^  self container isMethod or: [
                self name isAllDigits or: [
                        '*_anonymous_*' match: self name ]]

But VerveineJ does not follow the same pattern to name the anonymous  
classes. Currently, there is no _ in the name of the anonymous class. So if  
the container of the anonymous class is not a method, it won't be  
recognized as such.


Please fill in the labels with the following information:
* Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other
* Component-XXX

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #1 on issue 999 by [hidden email]: VerveineJ: management of  
the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

This heuristic does work for VerveineJ models given that VerveineJ will  
create anonymous classes inside methods so the container will respond true  
to isMethod.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #2 on issue 999 by [hidden email]: VerveineJ: management of  
the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

Yes and no.
It is true that if a class is contained in a method, VerveineJ considered  
it as anonymous and named it anonymous. Such a class is then considered as  
anonymous in Famix so everything works fine.

However, (and see issue 998), when a class is contained in an enumeration  
(Enum), VerveineJ named it anonymous but it is not considered as such since  
the pattern used by VerveineJ and checked in Famix are not the same.

In other terms, if we consider that the container of an anonymous class is  
always a method why we don't simplify the isAnonymousClass to:
FAMIXType >>isAnonymousClass
        ^  self container isMethod
If we consider that such a simplification is not possible, it means that  
the container of an anonymous class can be something else than a method and  
in that case, it would be great that VerveineJ and Famix follow the same  
pattern (otherwise we have some problems like in issue 998).

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 999 by [hidden email]: VerveineJ: management of  
the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

Ok, I understand the concern.

The reason for the current implementation of isAnonymousClass is that other  
importers (like inFamix) are less accurate than VerveineJ, and because of  
that we wanted to accommodate a bit of variations for this check.

So, the conclusion you draw from the implementation is not quite correct.

I like the definition of isAnonymousClass as it is in VerveineJ. For issue  
998, we have to find a different solution.

But, how did VerveineJ named the class as anonymous?



--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #4 on issue 999 by [hidden email]: VerveineJ: management of  
the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

In VerveineJ, the anonymous classes are named: anonymous(AParameter).

The thing between brackets always begins with a capital letter, but I don't  
know to what it corresponds.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #5 on issue 999 by [hidden email]: VerveineJ: management of  
the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

The thing inside the brackets is the type of the parameter, I think. In any  
case, do we agree to close the issue and tackle the Enum one separately?

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I think it should be kept open
- first, it is trivial to change how VerveineJ name the anonymous classes
- second, it would be good that verveineJ and Moose agree on this point.

unless we decide to change the default name in Moose (in that case I
would be for changing it accordingly in verveineJ)

nicoals

On 11/14/2013 09:25 PM, [hidden email] wrote:
>
> Comment #5 on issue 999 by [hidden email]: VerveineJ: management
> of the anonymous class
> http://code.google.com/p/moose-technology/issues/detail?id=999
>
> The thing inside the brackets is the type of the parameter, I think.
> In any case, do we agree to close the issue and tackle the Enum one
> separately?
>

--
Nicolas Anquetil -- RMod research team (Inria)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

nope
you got it right

It just seems unecessarily confusing to have to different naming conventions in a situation where one can trivially have only one (whatever it is)

nicolas

Hi,

On Thu, Nov 14, 2013 at 10:09 PM, Nicolas Anquetil <[hidden email]> wrote:

I think it should be kept open
- first, it is trivial to change how VerveineJ name the anonymous classes

- second, it would be good that verveineJ and Moose agree on this point.

unless we decide to change the default name in Moose (in that case I would be for changing it accordingly in verveineJ)

Perhaps I did not understand the issue then. The anonymous classes are called: 'Class.method(ParameterType)::anonymous(AnotherParameterType)

Why do you say there is a mismatch between Moose and VerveineJ? Is it because of the code in isAnonymousClass? If yes, then there is really no problem. The extra conditions in there are for inFamix and inFusion, not for VerveineJ.

Try this on any model:

model allTypes select: [:each | (each name beginsWith: 'anonymous') and: [each isAnonymousClass not] ]

and you will see that you will get an empty collection.

Or did I get something wrong?

Doru 

 

nicoals

On 11/14/2013 09:25 PM, [hidden email] wrote:

Comment #5 on issue 999 by [hidden email]: VerveineJ: management of the anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999

The thing inside the brackets is the type of the parameter, I think. In any case, do we agree to close the issue and tackle the Enum one separately?

--

Nicolas Anquetil -- RMod research team (Inria)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- 
Nicolas Anquetil -- RMod research team (Inria)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev