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