On Mar 19, 2011, at 8:39 PM, Igor Stasenko wrote: > I have no idea how Rpackage done internally but i think it should be > orthogonal > to MC.
a list of class and a list of methods smartly organized but no more. > 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. Exact Now reproducing the matching of MC makes everything more complex. > > 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. >
