PackageDependencyTest

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

PackageDependencyTest

Andreas.Raab
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


Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Casey Ransberger
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?

On Monday, March 1, 2010, Andreas Raab <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Andreas.Raab
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<[hidden email]>  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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Karl Ramberg
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<[hidden email]>  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
>>>
>>>
>>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Nicolas Cellier
Did someone had a look at
http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php

Nicolas

2010/3/2 Karl Ramberg <[hidden email]>:

> 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<[hidden email]>  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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Karl Ramberg
Nicolas Cellier skrev 2010-03-02 11:01:
> Did someone had a look at
> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
>    
This seems to cover much but installation in trunk fails

Karl


Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Karl Ramberg
In reply to this post by Nicolas Cellier
Nicolas Cellier skrev 2010-03-02 11:01:
> Did someone had a look at
> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
>
> Nicolas
>    
I added menu items to some of PackageInfo methods to PackageList to try
to understand the package struckture in the Etoys image.
http://source.squeak.org/etoys/PackageInfo-Base-kfr.3.mcz
Not that useful yet but a start

Karl

> 2010/3/2 Karl Ramberg<[hidden email]>:
>    
>> 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<[hidden email]>    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
>>>>>
>>>>>
>>>>>
>>>>>            
>>>>          
>>>
>>>
>>>        
>>
>>
>>      
>
>    


Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Chris Muller-3
In reply to this post by Karl Ramberg
I posted the tool I made for package-dependencies on SqueakMap, as a
project named, "MaSarPackage".  It utilizes
PackageInfo>>#externalUsers and #externalSubclasses at its core to
build a dependency-map which it uses to sort, in load dependency
order, a list of packages provided by the user.

The associated utility methods create a .sar file.

 - Chris

On Tue, Mar 2, 2010 at 3:19 AM, Karl Ramberg <[hidden email]> wrote:

> 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<[hidden email]>  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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Ian Trudel-2
I am not sure it is relevant to this discussion but I suddenly
remember Andreas wrote ConflictFinder last year. It's not in the trunk
nor on SqueakSource. I wonder if it has been forgotten about or
something...

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Andreas.Raab
On 3/2/2010 6:31 PM, Ian Trudel wrote:
> I am not sure it is relevant to this discussion but I suddenly
> remember Andreas wrote ConflictFinder last year. It's not in the trunk
> nor on SqueakSource. I wonder if it has been forgotten about or
> something...

I certainly haven't :-) But it's a completely different beast. It tests
whether code can be loaded together without causing ill side-effects
such as name conflicts etc.

I think this will come in handy as we consider adding additional
packages for the release and to ensure that they don't cause mayhem when
you load them all.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Casey Ransberger
In reply to this post by Nicolas Cellier
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
<[hidden email]> wrote:

> Did someone had a look at
> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
>
> Nicolas
>
> 2010/3/2 Karl Ramberg <[hidden email]>:
>> 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<[hidden email]>  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

Reply | Threaded
Open this post in threaded view
|

Re: PackageDependencyTest

Andreas.Raab
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
> <[hidden email]>  wrote:
>> Did someone had a look at
>> http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php
>>
>> Nicolas
>>
>> 2010/3/2 Karl Ramberg<[hidden email]>:
>>> 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<[hidden email]>    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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>