On 3/2/2010 7:16 PM, Ronald Spengler wrote:
> Yeah, I tried but I couldn't get it to work. Who wrote it? It would be
> awesome to get it working in trunk, but alas, I failed there.

I wrote a quick adoption of it because it'll come in very handy and it's 
straightforward. If anyone wants to improve on it, go right ahead.

Cheers,
   - Andreas

> On Tuesday, March 2, 2010, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com>  wrote:
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>