On second thought I think you're right.
Or more precisely a ClassExtension (as a subclass of FamixAssociation) should be
from aFamixMethod to aFamixClass
This way it would fit nicely in the new query system (forget about sure|potential ReferencedPackage, it's always a mess to understand what they do).
This is how it would look like with the new query DSL:
aFamixPackage queryOutgoingClassExtensions atPackageScope
basically takes all its class extensions, query the #to side which return classes, then ask for the packages of those classes: hence we get packages upon which aFamixPackage depends by class extensions.
aFamixPackage queryIncomingClassExntesions atPackageScope
basically takes all class extensions made by other packages, query the #to side which return methods, then ask for the packages of those mehods: hence we get packages which depends upon aFamixPackage by extending it.
On 21 janv. 2011, at 18:34, Nicolas Anquetil wrote:
I believe a package with an extension method should be seen as depending on the package owning the extended class (and also depending on the extended class)
Right now, this is not implemented in the various {sure|potential}ReferencedPackage , {sure|potential}ReferencedClass
After discussing with Simon, we believe that this would at least call for an explicit representation of the extension as an association.
This would go in Famix-Smalltalk
The question maybe how to represent this?
Simon sees it as an association between a package and a method: Me (package) defines an extension (the method)
I was rather thinking of a class/method association: Me (class) am extended by you (method)
and the reverse: me (method) extends you (class)
then of course we would need to implement the query system on top of this ...
what do you people think about this?
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev