Hi,
This method sends message parentClass to a FamixMethod (inv accessor). The method parentScope is not defined in FamixMethod. Should we take the parentScope of FamixClass ?
FamixGlobalVariable>>isPublic ^ self incomingAccesses anySatisfy: [:inv | inv accessor parentScope ~~ self parentScope]
Cheers --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---
On 8 sept. 09, at 14:43, Laval Jannik wrote:
Hi,
This method sends message parentClass to a FamixMethod (inv accessor). The method parentScope is not defined in FamixMethod. Should we take the parentScope of FamixClass ?
I have been struggling a bit with this one. There is no parentScope in FamixClass right now. But, the definition of the metamodel says that FamixType#container points to the namespace of the type.
My suggestion: - define a FAMIXType#parentScope which delegates to FamixType#container - define a FAMIXMethod#parentScope which calls parentType parentScope
in package FAMIX-Extensions. This way we get polymorphic behaviours between FamixMethod and FamixFunction.
But, I must say I am not completely satisfied with that. Problem comes from FAMIXContainerEntity#types <-> FAMIXType#container There are multiple ways to interpret this relationship depending on the concrete subclass of FAMIXContainerEntity and I am not sure they are equivalent.
FAMIXNamespace is the concrete subclass for the normal case. FAMIXPackage#types should not be used as there is a different relationship #childNamedEntities<->#parentPackage
But having FamixClass or even FamixMethod with some local #types is possible with Java for example... The same thing for procedural language: one could have a struct locally declared in a function I guess.
Well, not totally clear, an interesting topic to discuss.
FamixGlobalVariable>>isPublic ^ self incomingAccesses anySatisfy: [:inv | inv accessor parentScope ~~ self parentScope]
Cheers
Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
you lost me may be we should have a real UML diagram of FAMIX3.0
On 8 sept. 09, at 14:43, Laval Jannik wrote:
Hi,
This method sends message parentClass to a FamixMethod (inv accessor). The method parentScope is not defined in FamixMethod. Should we take the parentScope of FamixClass ?
I have been struggling a bit with this one. There is no parentScope in FamixClass right now. But, the definition of the metamodel says that FamixType#container points to the namespace of the type.
My suggestion:
- define a FAMIXType#parentScope which delegates to
FamixType#container
- define a FAMIXMethod#parentScope which calls parentType parentScope
in package FAMIX-Extensions. This way we get polymorphic behaviours between FamixMethod and FamixFunction.
But, I must say I am not completely satisfied with that. Problem comes from FAMIXContainerEntity#types <-> FAMIXType#container There are multiple ways to interpret this relationship depending on the concrete subclass of FAMIXContainerEntity and I am not sure they are equivalent.
FAMIXNamespace is the concrete subclass for the normal case. FAMIXPackage#types should not be used as there is a different relationship #childNamedEntities<->#parentPackage
But having FamixClass or even FamixMethod with some local #types is possible with Java for example... The same thing for procedural language: one could have a struct locally declared in a function I guess.
Well, not totally clear, an interesting topic to discuss.
FamixGlobalVariable>>isPublic ^ self incomingAccesses anySatisfy: [:inv | inv accessor parentScope ~~ self parentScope]
Cheers
Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 8 sept. 09, at 16:37, Stéphane Ducasse wrote:
you lost me may be we should have a real UML diagram of FAMIX3.0
MOFameView new viewFamixCore
But I am not sure it really helps
On 8 sept. 09, at 14:43, Laval Jannik wrote:
Hi,
This method sends message parentClass to a FamixMethod (inv accessor). The method parentScope is not defined in FamixMethod. Should we take the parentScope of FamixClass ?
I have been struggling a bit with this one. There is no parentScope in FamixClass right now. But, the definition of the metamodel says that FamixType#container points to the namespace of the type.
My suggestion:
- define a FAMIXType#parentScope which delegates to
FamixType#container
- define a FAMIXMethod#parentScope which calls parentType parentScope
in package FAMIX-Extensions. This way we get polymorphic behaviours between FamixMethod and FamixFunction.
But, I must say I am not completely satisfied with that. Problem comes from FAMIXContainerEntity#types <-> FAMIXType#container There are multiple ways to interpret this relationship depending on the concrete subclass of FAMIXContainerEntity and I am not sure they are equivalent.
FAMIXNamespace is the concrete subclass for the normal case. FAMIXPackage#types should not be used as there is a different relationship #childNamedEntities<->#parentPackage
But having FamixClass or even FamixMethod with some local #types is possible with Java for example... The same thing for procedural language: one could have a struct locally declared in a function I guess.
Well, not totally clear, an interesting topic to discuss.
FamixGlobalVariable>>isPublic ^ self incomingAccesses anySatisfy: [:inv | inv accessor parentScope ~~ self parentScope]
Cheers
Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
On 8 sept. 09, at 15:24, Simon Denier wrote:
On 8 sept. 09, at 14:43, Laval Jannik wrote:
Hi,
This method sends message parentClass to a FamixMethod (inv accessor). The method parentScope is not defined in FamixMethod. Should we take the parentScope of FamixClass ?
I have been struggling a bit with this one. There is no parentScope in FamixClass right now. But, the definition of the metamodel says that FamixType#container points to the namespace of the type.
My suggestion:
- define a FAMIXType#parentScope which delegates to
FamixType#container
- define a FAMIXMethod#parentScope which calls parentType parentScope
Fixed
Now I wonder. Since there is no namespace in Pharo, or just a 'unique' namespace, this method always returns false :) in the case of Pharo code.
FamixGlobalVariable>>isPublic ^ self incomingAccesses anySatisfy: [:inv | inv accessor parentScope ~~ self parentScope]
-- Simon
-
Laval Jannik -
Simon Denier -
Stéphane Ducasse