Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ?
Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ? I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ? At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0). Thierry ________________________________________ De : [email protected] [[email protected]] de la part de Esteban Lorenzano [[email protected]] Date d'envoi : dimanche 5 août 2012 14:44 À : [email protected] Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage AFAIK, we decided (because that was the best migration path possible), when you have packages X, X-A, X-B, X-C, just to keep package "X", then add class tags (A, B, C) to corresponding classes. Of course that also means that we need to update tools (nautilus) to show that tags, but thats no so difficult. Esteban On Aug 5, 2012, at 2:33 PM, Stéphane Ducasse <[email protected]> wrote: > > On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote: > >> What Mariano means is that you can have MCPackage(X) containing categories >> X-A, X-B, X-C. When that package is loaded today, three RPackages are >> created: X-A, X-B, X-C. So RPackages are more mapped from categories that >> from MCPackages. > > we decided that it will be one package with classes having corresponding tags. > But we should do it. > Again nothing should be mapped from MCPackages (MCPackages should not be used > it is an internal class of MC). > > > >>> PackageInfo has a large APi that is often not used. >>> So I would suggest that we reduce the PackageInfo API first because it will >>> lower the stress on RPackage to be offer a >>> compatible interface. >>> All the methods in the compatibility should somehow disappear or only serve >>> as purpose to help temporary >>> backwards compat. >>> >>> >>> I agree. But if you want to remove in the future PackageInfo, then RPackage >>> HAS to provide a way to get the classes/extension methods of a MCPackage. >>> That's why I need #allDefinedClasses and #allDefinedExtensionMethods >> >> Mariano if RPackage represents a MCPackage then RPackage offers all the >> correct queries to get the classes extended, method extensions and so >> let me know if you do not see it because I payed extreme attention to that. >> >> RPackage>>defineMethodsForClass: >> definedSelectorForClass: >> extendedClassames >> extendedClasses >> extensionMethods >> extensionMethodsForClass: >> extensionSelectors >> extensionSelectorsForClass: >> methodsForClass: >> selectorsForClass: >> >> Let me repeat it. We do not need the compatibility layer. >> Now it may be that (since rpackage was pushed fast in the image) that the >> importer from PackageInfo to Rpackage did not cover all the cases >> but this is clearly another issue. >> >> Stef >> >>> >>> >>> >>> >>> >>> What do you think? >>> >>> Stef >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> > >
