Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ]
FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ]
Now does it make sense to have a similar definition for FAMIXMethod?
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope.
In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations
but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses
I am wondering if it would not be better to just say:
FAMIXMethod>>qIncomingAccesses
^ Array new
Or maybe I'm just trying to split hairs
-- Simon
Hi!
I do not understand. qIncomingAccesses is not defined in my image. But what does it mean? What "q" is for? "incomingAccesses" is an explicit name. I am lost
Alexandre
On 12 Jan 2011, at 14:51, Simon Denier wrote:
Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ]
FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ]
Now does it make sense to have a similar definition for FAMIXMethod?
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope.
In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations
but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses
I am wondering if it would not be better to just say:
FAMIXMethod>>qIncomingAccesses
^ Array new
Or maybe I'm just trying to split hairs
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Alex, I understood that q in qIncomigAccesses was some kind of typo. I ignored it and it made some sense.
----- Mail original -----
De: "Simon Denier" sdenier@free.fr À: "Moose-related development" moose-dev@iam.unibe.ch Cc: "Simon Denier" sdenier@free.fr Envoyé: Mercredi 12 Janvier 2011 18:51:27 Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ]
FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ]
Now does it make sense to have a similar definition for FAMIXMethod?
I think you demonstrated that it does not make sense. Method are closed box that don't have persistent state. You cannot access anything inside them except from within themselves.
Why would you want to have FAMIXmethod>>incomigAccesses ?
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope.
In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations
but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses
I am wondering if it would not be better to just say:
FAMIXMethod>>qIncomingAccesses
^ Array new
Or maybe I'm just trying to split hairs
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yeah, don't worry about the q for now, it's just some namespace to avoid potential conflicts with regular Famix extensions.
On 12 janv. 2011, at 21:24, Nicolas Anquetil wrote:
Alex, I understood that q in qIncomigAccesses was some kind of typo. I ignored it and it made some sense.
----- Mail original -----
De: "Simon Denier" sdenier@free.fr À: "Moose-related development" moose-dev@iam.unibe.ch Cc: "Simon Denier" sdenier@free.fr Envoyé: Mercredi 12 Janvier 2011 18:51:27 Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ]
FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ]
Now does it make sense to have a similar definition for FAMIXMethod?
I think you demonstrated that it does not make sense. Method are closed box that don't have persistent state. You cannot access anything inside them except from within themselves.
Why would you want to have FAMIXmethod>>incomigAccesses ?
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope.
In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations
but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses
I am wondering if it would not be better to just say:
FAMIXMethod>>qIncomingAccesses
^ Array new
Or maybe I'm just trying to split hairs
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Incoming and outgoing is only for specifying the relation direction on the (contained) element, not for specifying the outer or inner scope of the relation origin.
So, FAMIXMethod>>qIncomingAccesses should definitely not be "Array new". It should be like you said first:
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
Cheers, Doru
On 12 Jan 2011, at 22:15, Simon Denier wrote:
Yeah, don't worry about the q for now, it's just some namespace to avoid potential conflicts with regular Famix extensions.
On 12 janv. 2011, at 21:24, Nicolas Anquetil wrote:
Alex, I understood that q in qIncomigAccesses was some kind of typo. I ignored it and it made some sense.
----- Mail original -----
De: "Simon Denier" sdenier@free.fr À: "Moose-related development" moose-dev@iam.unibe.ch Cc: "Simon Denier" sdenier@free.fr Envoyé: Mercredi 12 Janvier 2011 18:51:27 Objet: [Moose-dev] What's a sensible definition of FAMIXMethod>>incomingAccesses? Take a look at the following definitions:
FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ]
FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ]
Now does it make sense to have a similar definition for FAMIXMethod?
I think you demonstrated that it does not make sense. Method are closed box that don't have persistent state. You cannot access anything inside them except from within themselves.
Why would you want to have FAMIXmethod>>incomigAccesses ?
FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself
We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope.
In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations
but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses
I am wondering if it would not be better to just say:
FAMIXMethod>>qIncomingAccesses
^ Array new
Or maybe I'm just trying to split hairs
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
-
Alexandre Bergel -
Nicolas Anquetil -
Simon Denier -
Simon Denier -
Tudor Girba