21 Jan
2011
21 Jan
'11
6:34 p.m.
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
21 Jan
21 Jan
7:49 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
10:11 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
11 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
22 Jan
22 Jan
12:22 a.m.
On 21 janv. 2011, at 23:00, Stéphane Ducasse wrote:
On Jan 21, 2011, at 10:11 PM, Simon Denier 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
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?
9:44 a.m.
On Jan 22, 2011, at 12:22 AM, Simon Denier wrote:
On 21 janv. 2011, at 23:00, 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?
On Jan 21, 2011, at 10:11 PM, Simon Denier 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).
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? 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
23 Jan
23 Jan
12:25 a.m.
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?
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
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?
21 Jan
21 Jan
11 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5083
days inactive
5084
days old
7 comments
4 participants
participants (4)
-
Alexandre Bergel -
Nicolas Anquetil -
Simon Denier -
Stéphane Ducasse