extension method should reference own class ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

extension method should reference own class ?

Nicolas Anquetil

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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

Alexandre Bergel
> 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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

simondenier
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:


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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

simondenier

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




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: extension method should reference own class ?

simondenier

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