[squeak-dev] Re: PackageDependencyTest
karlramberg at gmail.com
Tue Mar 2 09:19:55 UTC 2010
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 ?
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.
> 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
> (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.
> - 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.
>>> - Andreas
More information about the Squeak-dev