[squeak-dev] Re: PackageDependencyTest

Karl Ramberg karlramberg at gmail.com
Tue Mar 2 09:19:55 UTC 2010


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




More information about the Squeak-dev mailing list