2 Aug
2012
2 Aug
'12
9:24 a.m.
we work on coupling metrics that measure how much a package depends on
other packages (can you reuse it without the others).
Even if it is trough a method added by extension, if package A use
something in package B, then A needs B (or if you prefer A+C needs B)
The current semantic does not show this because the extending method
will be part of package C (the one that introduces the extension) and
therefore C will depend on B (which seem correct to me), but A will not
depend on B ...
So with extensions, we can consider that both A and C depend on B.
This is something that the coupling metrics do not consider.
So we have to make a choice.
For coherence with the same experiment on Java systems, we prefer to say
that only A depends on B.
But tis is not how famix and moose chef see things ...
Additionaly, we have a metric whose results are useless in the presence
of extensions.
nicolas
On 01/08/12 20:39, Tudor Girba wrote:
Hi Nicolas,
The current semantics for both methods and queryOutgoingReferences are quite fine.
As I understand you want to count the amount of references that the code inside a package
induces. So, this includes both the extension methods and the defined methods. Why do you
see this as a problem?
Cheers,
Doru
On 31 Jul 2012, at 16:21, Nicolas Anquetil wrote:
Another MooseChef decision:
aPackage queryOutgoingReferences
returns all the FamixReferences made from aPackage.
this is implemented by taking all methods (self methods) in the package and asking them
what reference they make.
And we have
FAMIXPackage>>methods
^ self localMethods union: self extensionMethods
So when asking a package what external references it makes, we get references stemming
from methods that extend classes of other packages.
We found this while computing a coupling metric for packages.
So the solution would be easy to implement, but we are not sure what is the best solution
?
- we could change FAMIXPackage>>methods (methods belong to the package that owns
their class)
- we could change queryOutgoingReferences (references/invocation/accesses stem from the
methods in the classes in the package, not from the methods in the package)
- or we could change our metric
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev