Stef, I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... Dale On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote: > Hi guys > > we need to think about package: > > right now we have a new implementation that is fast, robust and supports well > a new generation of tools (glamour, nautilus...). > We are capturing all system events and we would be more or less ready to > remove systemNotifier and use Announcement > instead. > RPackage can live also on the side of PackageInfo for a while but it would be > better to have the shortest possible period of co-existence. > > Now one of the problem I see is that we may not have a smooth transition > because: > - Rpackage does not rely on category tagging matching. > - It is simpler to have a mapping from current categories to packages > - Now it means that we could load a package in the system and it would > be turned into several RPackages > so this means that configuration would have to be adapted. > > - marcus was suggesting me to create a package with the same contents > as the one of loaded by MC. > and to have tags to only represent categories. > > Now my time is short so I will > - probably not implement tags > - check again the implementation of RPackage and in particular the > necessary compatibility layer, because I saw some strange > code. > - check the MC dependency on method category conventions, because some > logic is not defined in the right place > like overrides in the MC tools and not in the PackageInfo > - check how a package gets created when loaded: the key question is > that there is a problem to rely on categories to > associate classes to packages because we can end up with overlapping > (normally the IDE captures the category renames > and change the packages accordingly). > - we should not rely on most-specific-category kind of pattern matching. > > So if you have suggestion please talk now. > > > Stef
