extension method should reference own class ?
Locked
extension method should reference own class ?
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: extension method should reference own class ?
|
|
> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: extension method should reference own class ?
|
|
In reply to this post by Nicolas Anquetil
<base href="x-msg://14/">
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:
-- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: extension method should reference own class ?
|
|
In reply to this post by Nicolas Anquetil
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 > [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 |
Re: extension method should reference own class ?
|
|
In reply to this post by simondenier
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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > _______________________________________________ > 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 |
Re: extension method should reference own class ?
|
|
On 21 janv. 2011, at 23:00, Stéphane Ducasse wrote:
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: extension method should reference own class ?
|
|
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 > [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 |
Re: extension method should reference own class ?
|
|
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |