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(a)free.fr>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Cc: "Simon Denier" <sdenier(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev