[Moose-dev] Re: issue 147: FamixGlobalVariable>>isPublic crashes
stephane.ducasse at inria.fr
Tue Sep 8 16:37:03 MEST 2009
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:
>> 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
> - 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.
>> ^ self incomingAccesses anySatisfy: [:inv |
>> inv accessor parentScope ~~ self parentScope]
>> Jannik Laval
>> PhD Student - Rmod Team - INRIA
>> Certified Project Management Associate (IPMA)
>> Moose-dev mailing list
>> Moose-dev at iam.unibe.ch
> Moose-dev mailing list
> Moose-dev at iam.unibe.ch
More information about the Moose-dev