[squeak-dev] PackageDependencyTest

Ronald Spengler ron.spengler at gmail.com
Wed Mar 3 03:16:32 UTC 2010


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.

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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>

-- 
Ron



More information about the Squeak-dev mailing list