2012/9/7 Mariano Martinez Peck <[email protected]>: > I am also for the 2 option :) > > > On Fri, Sep 7, 2012 at 6:13 PM, Esteban Lorenzano <[email protected]> > wrote: >> >> Hi, >> >> As you know, we want to replace the old PackageInfo structure with >> RPackage. Last weeks Pharo 2.0 has been really unstable because of this >> effort, and it will be unstable yet a few days more, so I want to review the >> actions we are taking, so you know why this happnes and the result we want >> to obtain. >> So... first: Why replace PackageInfo and PackageOrganizer? The short >> answer is: because they suck :) The more or less long answer is: because >> their existence introduces a lot of penalties in the system, and forces to a >> lot of workarounds to manage what should be a simple system categories >> manager... take for instance the match MCPackage-PackageInfo-Class >> categories. Each MCPackage maps to a unique PackageInfo, but package info >> contains string pattern matched class categories. Tools uses this and >> well... performance is frankly disappointing in many case. Like this, there >> are lots of other reasons. >> So... RPackage will solve this by keeping a view of the system, not having >> to calculate it everytime. RPackage will keep also the list of classes, >> extension, etc. so tools can operate with them in a better/faster way. >> >> Question is: How to migrate in the less painful way? >> >> Attempt 1) Let each RPackage be one PackageInfo. >> >> We first thought this was the best path so, we spend some time moving in >> that direction. The advantage is that migration from Monticello and >> PackageInfo is trivial, but then the problems started to happen: PackageInfo >> (and current RPackage) contains N class categories so, there is an impedance >> mismatch between what we was seeing and what users/tools expect (they work >> with class categories, not with RPackage or PackageInfo). >> To solve that, we added class categories as RPackage tags (yep RPackage >> allows you to tag classes). But then we need to update in ver annoying ways >> the tools. And we also has now the fact that class categories are now a tag >> into an RPackage. Something really obscure and that was causing a lot of >> pain... >>
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? - Does a class know (directly point to) its package, or is it a service provided by some helper object? - Does a method know (directly point to) its package, or is it a service provided by some helper object? - Are there unpackaged classes/methods (pointing to nil?), is there a service to discover them? - What is the relation with st80 classification (class categories and method protocols)? Is it completely orthogonal? - Should class/methods have multi-classification (belong to several categories protocols)? 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. 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). >> 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). Nicolas > > > > -- > Mariano > http://marianopeck.wordpress.com >
