>> >>> 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. >> >> No this is not a problem, because we can save the package with the * >> notation and category even if we do not need that. > ........... >> >> Now what other system like gemstone could do is also to copy the pharo >> package implementation because these are two classes. > > Stef, > > Over the long haul I would agree that migration to the newer model is a good > idea and gemstone could install the code (when tool support becomes available > in GemStone) and as long as there is a transition period where RPackage isn't > _required_, then I think that things can work smoothly...
Yes I understand. Now we should be able to find a solution based on category (without subcat matching). > > Dale
