PackageDependencyTest
Locked
 
|
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 |
|
|
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 |
|
|
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 >> >> >> > |
|
|
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 >>> >>> >>> >> > > > |
|
|
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 >>>> >>>> >>>> >>> >> >> >> > > > |
|
|
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 |
|
|
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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> > > |
|
|
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 >>>> >>>> >>>> >>> >> >> >> > > > |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |