Good thing to have a rationale for where you want to be going and why... It would be interesting to have it documented.For example: - A package is holding strong references to class/methods belonging to it or not?
did you read the class comment of RPackage? Because this is explained normally. Now the answer a RPackage does not hold references to class or compiledMethod but to class names and selectors so that it could potentially be used for now working classes.
- Does a class know (directly point to) its package, or is it a service provided by some helper object?
RPackageOrganizer so far we did not modify class but manage the invariant class/package using announcement
- Does a method know (directly point to) its package, or is it a service provided by some helper object?
CompiledMethod package and this is manager by PackageOrganizer
- Are there unpackaged classes/methods (pointing to nil?), is there a service to discover them?
Not that I know.
- What is the relation with st80 classification (class categories and method protocols)? Is it completely orthogonal?
Totally.
- Should class/methods have multi-classification (belong to several categories protocols)?
A class belongs to only one packages Now you can have tags (I implemented it but may be we will not use it) to have virtual categories For methods packages are orthogonal to categories (now we are maintaining for the moment the * notation).
You can call that tags if you want... pro/cons for each point
Then it's another thing to tell how you will reach these goals, and if/how you will maintain compatibility with MC (a vital tool) or other tools (browsers nautilus RB change list/change sorter etc...) - which might be possible by faking categories/protocols.
the compatibility is first when you load -> * star notation in the mcz -> category announcement -> extension in the repackage saving -> we should check that the package and the categories get the same contents -> saving with * in category So for now we will maintain a compatibility and in the future we will see.
For french: Je dirai qu'on a l'eau à la bouche, mais qu'on reste un peu sur notre faim ;)
So, we rolled back...
Attempt 2) Let each Class Category be one RPackage.
Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways.
...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal.
Good, if the system was too complex in order to analyze all implications and completely planify the change path, then trial and error might be a solution, it's not a shame, but you have to write your goals to better remind them, and maybe make some amendments to your rationale because of some unanticipated features (and providing some degree of compatibility can lead to additional features).
Compatibitilty of MC and configurations will be maintain. If we could have got rid of the last one it would have solved a lot of our pain.
PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :)
Cheers, Esteban
Such a change will require a stable and if possible well documented API (which should be quite straightforward once you have rationalized your design).
Have a look at the RPackage class. It is really nice. The pain is not it, the pain is the system and the pattern matching and event and â¦. and having packages and categories. Stef
Nicolas
-- Mariano http://marianopeck.wordpress.com