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
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)
What Simon and you think is not contradictory isn't it? I think that both way should co-exist.
Alexandre
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.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
On Jan 21, 2011, at 10:11 PM, Simon Denier wrote:
On second thought I think you're right.
Or more precisely a ClassExtension (as a subclass of FamixAssociation) should be from aFamixMethod to aFamixClass
why?
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.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 21 janv. 2011, at 23:00, Stéphane Ducasse wrote:
On Jan 21, 2011, at 10:11 PM, Simon Denier wrote:
On second thought I think you're right.
Or more precisely a ClassExtension (as a subclass of FamixAssociation) should be from aFamixMethod to aFamixClass
why?
FamixPackages already have methods to retrieve class extension (as well as extended classes).
Now if we want class extensions as first-class entities, I think it's better to take the smallest granularity of representation, to be able to manipulate one class extension separately from another (for example Orion could manipulate extensions one by one). In this case that would based on the extension supported by a FamixMethod and the extended FamixClass.
The other reason I believe in this solution is that it seems to fit nicely with the current work on queries :)
-- Simon Denier
On Jan 22, 2011, at 12:22 AM, Simon Denier wrote:
On 21 janv. 2011, at 23:00, Stéphane Ducasse wrote:
On Jan 21, 2011, at 10:11 PM, Simon Denier wrote:
On second thought I think you're right.
Or more precisely a ClassExtension (as a subclass of FamixAssociation) should be from aFamixMethod to aFamixClass
why?
FamixPackages already have methods to retrieve class extension (as well as extended classes).
Now if we want class extensions as first-class entities, I think it's better to take the smallest granularity of representation, to be able to manipulate one class extension separately from another (for example Orion could manipulate extensions one by one).
ah ok
now what does it means Point classExtensions -> list of methods? Method(asURL) extendedFromClass does not work Method(asURL) extendedFromClass because I know that asURL is in String so the only information I need is where does it comes from -> Network package?
In this case that would based on the extension supported by a FamixMethod and the extended FamixClass.
I still do not get it.
I have a method symbol: asURL belongstoclass: String packagedIn: Network
so how a relation between String and asURL can convey something more than that?
The other reason I believe in this solution is that it seems to fit nicely with the current work on queries :)
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 22 janv. 2011, at 09:44, Stéphane Ducasse wrote:
ah ok
now what does it means Point classExtensions -> list of methods?
Method(asURL) extendedFromClass does not work Method(asURL) extendedFromClass because I know that asURL is in String so the only information I need is where does it comes from
-> Network package?
In this case that would based on the extension supported by a FamixMethod and the extended FamixClass.
I still do not get it.
I have a method symbol: asURL belongstoclass: String packagedIn: Network
so how a relation between String and asURL can convey something more than that?
I'm not talking about replacing the current representation of class extensions. It's more like, how to represent a class extension (which is a 3-way relationship) by a two-way relationship so that it behaves like other FamixAssociations? (especially in the context of MooseChef)
The best way to illustrate my point (because it's also the main selling point of MooseChef) is to explain 'scoping' or 'scaling' dependencies: getting a dependency at a higher granularity (for example, seeing dependencies at package level from invocations at method level).
Consider the invocation 'a invokes b', that is a dependency from a to b. Now imagine that I can scale/scope both sides independently (this is not exactly how it works but it's for the idea)
a atClassScope invokes b would mean 'Class defining a depends on b'
a invokes b atPackageScope would mean 'method a depends on package defining b'
Now take the dependency 'method a extends class B' and scale both sides at package level method a atPackageScope extends class B atPackageScope ---> 'package of method a depends on package of class B' which gives the right dependency (the extension package depends on the extended package).
This wouldn't work so nicely if the relationship was modeled in a different way, like 'class a extended by method b', or 'method m class extension from package X'
-- Simon Denier
extension fits more package. Because without container of set of declaration the world is flat and extension does not have meaning.
Stef
On Jan 21, 2011, at 6:34 PM, 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.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Nicolas Anquetil -
Simon Denier -
Stéphane Ducasse