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@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@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@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@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@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@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
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
>
> --
> Andre Hora
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev@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@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Andre Hora