I have no idea how Rpackage done internally but i think it should be orthogonal to MC. You can implement import/export layers between MC and RPackage and make it follow any rules you want (current ones), but internal organization can be completely different.
On 19 March 2011 19:17, Guillermo Polito <[email protected]> wrote: > BTW, for smooth transition, why not just replace usages of PackageInfo by > RPackage keeping everything working as today? And after that, we can > improve the way we use it. > > In two words, why not replace only infrastructure instead of infrastructure > and behavior at the same time? Doing both together is kind of complex and > easy to make mistakes... > > But maybe it's easier (or nicer) to replace everything together... :P > > Guille > > On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <[email protected]> wrote: >> >> 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 >> >> > > -- Best regards, Igor Stasenko AKA sig.
