Did someone had a look at
http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php

Nicolas

2010/3/2 Karl Ramberg <karlramberg at gmail.com>:
> Hi.
> Is there a way to find which package sends to which methods, so one can
> detect methods that are more likely to
> be extension to a package ?
>
> Karl
>
> Andreas Raab skrev 2010-03-02 07:17:
>>
>> On 3/1/2010 9:55 PM, Ronald Spengler wrote:
>>>
>>> Andreas, this is fantastic! While I'm keeping myself from digging into
>>> anything not related to 4.0 right now, I'd love it if you might point
>>> me at where to look for how this works, such that I can explore
>>> further when I have time? I found myself frustrated with the often
>>> bizarre dependency graph in Squeak almost right away when I found code
>>> in the compiler (which I removed in trunk) that was coupled to the
>>> browser's pretty-print feature.
>>>
>>> I've toyed with dependency analysis in squeak, but I lack the
>>> experience with the system to make meaningful sense of it.
>>>
>>> Are these just dependencies that you happen to be aware of, or is
>>> there a tool or technique that you used to find them?
>>
>> Nothing fancy. Just direct references to classes. The reasoning being that
>> if you refer to a class, then you're relying on it to be there. If you're
>> aware of it's absence you would write it differently. Compare, for example:
>>
>>  x := Array new: 10.
>>
>> vs.
>>
>>  x := Smalltalk at: #B3DRenderEngine ifPresent:[:cls| cls new].
>>
>> In the first case you have a hard reference to class Array so, yeah, you
>> kinda depend on class Array being there. In the second, you haven't - in
>> fact you've written your code specifically such that it can deal with the
>> absence of the class.
>>
>> Coincidentally, this is one of the reasons I like the #is: protocol. When
>> you test for class membership you are *always* prepared for that test to be
>> failing so the hard reference to the class, along the lines of:
>>
>>    (foo isKindOf: FooBarMorph) ifTrue:[...]
>>
>> is completely pointless. If you're writing this already, you might as well
>> avoid that dependency and write:
>>
>>    (foo is: #FooBarMorph) ifTrue:[...]
>>
>> etc. I'd really like to see #is: integrated so that it can used
>> interchangeably with #isKindOf: but using the name instead of the type.
>>
>> Cheers,
>>  - Andreas
>>
>>
>>>
>>> On Monday, March 1, 2010, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>>
>>>> Folks -
>>>>
>>>> I just posted a set of tests for various package dependencies. I'm
>>>> hoping that this will serve two purposes:
>>>>
>>>> 1) Inspire people to pick up and remove unneeded dependencies. For
>>>> example, if look at testCollections you'll find MorphicExtras listed among
>>>> the Collection dependencies.
>>>>
>>>> If you remove the dependency from the test the test will fail and you
>>>> can look at the dependencies to see that there's a dependency on BookMorph.
>>>> A bit of digging leads you to TextSqkPageLink in Collections-Text and you
>>>> can now look at how to rewrite this to avoid the dependency. (we should keep
>>>> better track of the dependencies; keeping original method references would
>>>> be good)
>>>>
>>>> Effectively this is sort of a test driven untanglement approach - you
>>>> pick a particular dependency, make the test fail, track it down, remove it,
>>>> make the test pass.
>>>>
>>>> 2) Keep track of the existing dependencies and ensure they don't get any
>>>> worse than they are today. These tests can hopefully raise awareness to
>>>> these issues by documenting the dependencies and failing if new ones get
>>>> added carelessly.
>>>>
>>>> Cheers,
>>>>   - Andreas
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>