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... > > 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. > > 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 > > -- Mariano http://marianopeck.wordpress.com
