New Prerequisite Engine
Last published: October 2, 2008 by 'tkogan'
Defines 6 Classes
Extends 13 Classes
This package overrides the "compute prereqs" option in the RefactoringBrowser for vw7. I wouldn't try using it on earlier versions. It's also dependent on StORE (which I guess you've got loaded it you're browsing this).
Prerequisite candidates are all packages in the system which are NOT found in the Base VisualWorks bundle.
A prerequisite is found to exist when any of the following conditions exist:
1) the superclass of one of your defined classes is in another package
2) the defining environment (namespace) of any of your defined namespaces or classes is in another package
3) any of your classes or namespaces are extended*
4) any of your methods** refers to a global (share, namespace, class) which is in another package or send a message which is uniquely defined in exaclty one other package
*classes are extended when either methods or shared variables are added to them outside of the defining package, namespaces are extended when shared variables are added to them outside of the defining package
**methods includes those which belong to defined classes, those which are extended, AND initializers for shared variables
I found that having this was really cool. But sometimes I didn't trust the thing. What the prereq computation often turned up seemed wrong. I found myself wanting to know _WHY_ a given prerequisite was chosen. So, I added the ability to right click a menu with one option: Why? over the prerequisite list. This will essentially reverse the prerequisite computation for that particular prerequisite, and pop up a report detailing the reason(s) it was computed.
Caveat Emptor: The one type of prereq computation that I just don't know how to do is polymorphic calls. For example: In your package you have a method which creates a collection of Foo's and collect:'s their names. Then imagine that to get the 'name' ivar from your foo's, you added an extension method in another package called #name. Rule #4 would not be invoked, because the method #name is actually defined in a number of "packages" throughout the system.
Additions in this version:
1) The generated prerequiste list is now ordered as an alphabetic listing of must prerequisites followed by an alphabetic listing of prerequisites which look probable because of single implementor sites.
2) A check box which will copy the deployments to developments automatically on apply. Its initial state is set based on whether the matched to begin with.
3) A check box which will omit duplicates from the computed prerequisites, i.e. if computed prereqs are A and B, but B is also a prerequisite of A, then remove B from the list.
1) fixed for bundle prerequisite calculation (for both backtrack and computation)
2) start for a menu pick 'Which bundle contains this prerequisite package?'
3) ability to mark prerequisites either "ignored" or "explicit" to handle the cases that the engine can't deal with correctly