31 Jul
2012
31 Jul
'12
4:21 p.m.
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
31 Jul
31 Jul
9:51 p.m.
it would be good to methodExtens
aPackage methods =
aPackage methodExtensions +
aPackage methodDefined?
aClass extendedMethods
have at RPackage because I spent time on the API.
On Jul 31, 2012, at 4:21 PM, 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
1 Aug
1 Aug
8:39 p.m.
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."
2 Aug
2 Aug
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
9:32 a.m.
Hi,
I still do not understand :).
Let's be more specific. As I understand we could use the following example:
- package A = FAMIX-Core
- package B = Mondrian
- package C = Moose-Finder
The Moose-Finder extends FAMIX entities with visualization methods
that depend on Mondrian. This decision was taken exactly so that FAMIX
does not depend on Mondrian. So, why would you want to see FAMIX-Core
depend on Mondrian?
Cheers,
Doru
On Thu, Aug 2, 2012 at 9:24 AM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> wrote:
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:
--
www.tudorgirba.com
"Every thing has its own flow"
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 
11:57 a.m.
A simple example.
If you create a model with the package Fame-Util, then, inspect such
package:
"1"
(self classes flatCollectAsSet: [ :each | each queryOutgoingDependencies
atPackageScope ]) size " = 7"
"2"
(self queryOutgoingDependencies atPackageScope asSet) size " = 12"
What in a first moment is strange. At least when we are implementing
metrics..
We would expect the same outgoing references (same size) bor both class
level (1) and package level (2).
I know that the second one is bigger because it checks all methods,
including extensions....but....
On Thu, Aug 2, 2012 at 9:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
I still do not understand :).
Let's be more specific. As I understand we could use the following example:
- package A = FAMIX-Core
- package B = Mondrian
- package C = Moose-Finder
The Moose-Finder extends FAMIX entities with visualization methods
that depend on Mondrian. This decision was taken exactly so that FAMIX
does not depend on Mondrian. So, why would you want to see FAMIX-Core
depend on Mondrian?
Cheers,
Doru
On Thu, Aug 2, 2012 at 9:24 AM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Andre Hora
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
3:08 p.m.
Great example. I think it is now clear that your expectations do not
match the meaning of FAMIX, at least not when you have a Smalltalk
system. Am I right?
Cheers,
Doru
On Thu, Aug 2, 2012 at 11:57 AM, Andre Hora <andrehoraa(a)gmail.com> wrote:
A simple example.
If you create a model with the package Fame-Util, then, inspect such
package:
"1"
(self classes flatCollectAsSet: [ :each | each queryOutgoingDependencies
atPackageScope ]) size " = 7"
"2"
(self queryOutgoingDependencies atPackageScope asSet) size " = 12"
What in a first moment is strange. At least when we are implementing
metrics..
We would expect the same outgoing references (same size) bor both class
level (1) and package level (2).
I know that the second one is bigger because it checks all methods,
including extensions....but....
On Thu, Aug 2, 2012 at 9:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
I still do not understand :).
Let's be more specific. As I understand we could use the following
example:
- package A = FAMIX-Core
- package B = Mondrian
- package C = Moose-Finder
The Moose-Finder extends FAMIX entities with visualization methods
that depend on Mondrian. This decision was taken exactly so that FAMIX
does not depend on Mondrian. So, why would you want to see FAMIX-Core
depend on Mondrian?
Cheers,
Doru
On Thu, Aug 2, 2012 at 9:24 AM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> wrote:
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:42 p.m.
Yes. And that's why I have said "in a first moment", because for this
behavior is quite ok for a Smalltalk model.
So, I think we need to adapt our metric and not to touch in MooseChef..:)
On Thu, Aug 2, 2012 at 3:08 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Great example. I think it is now clear that your
expectations do not
match the meaning of FAMIX, at least not when you have a Smalltalk
system. Am I right?
Cheers,
Doru
On Thu, Aug 2, 2012 at 11:57 AM, Andre Hora <andrehoraa(a)gmail.com> wrote:
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Andre Hora
A simple example.
If you create a model with the package Fame-Util, then, inspect such
package:
"1"
(self classes flatCollectAsSet: [ :each | each queryOutgoingDependencies
atPackageScope ]) size " = 7"
"2"
(self queryOutgoingDependencies atPackageScope asSet) size " = 12"
What in a first moment is strange. At least when we are implementing
metrics..
We would expect the same outgoing references (same size) bor both class
level (1) and package level (2).
I know that the second one is bigger because it checks all methods,
including extensions....but....
On Thu, Aug 2, 2012 at 9:32 AM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
>
> Hi,
>
> I still do not understand :).
>
> Let's be more specific. As I understand we could use the following
> example:
> - package A = FAMIX-Core
> - package B = Mondrian
> - package C = Moose-Finder
>
> The Moose-Finder extends FAMIX entities with visualization methods
> that depend on Mondrian. This decision was taken exactly so that FAMIX
> does not depend on Mondrian. So, why would you want to see FAMIX-Core
> depend on Mondrian?
>
> Cheers,
> Doru
>
>
> On Thu, Aug 2, 2012 at 9:24 AM, Nicolas Anquetil
> <Nicolas.Anquetil(a)inria.fr> wrote:
> >
> > 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4294
days inactive
4296
days old
7 comments
4 participants
participants (4)
-
Andre Hora -
Nicolas Anquetil -
Stéphane Ducasse -
Tudor Girba