Makes sense to me ... Dale
On Mar 19, 2011, at 2:55 PM, Tudor Girba wrote: > Hi Stef, > > Thanks a lot for all this effort. > > I will reiterate again the original idea, which I still believe would work > best. > > RPackage is meant to become the organization entity in the image. MCPackage > will still be needed for versioning. Furthermore, for a while, categories > will still remain in the system for a while as an implementation detail. > RPackages mirror each category. > > The first step would be to keep loading from Monticello exactly like it is > now: it will create Categories, and this will mirror in RPackages. > > The next step is to provide a tool that provides only a 1-1 mapping between > MC and RPackages that we can use for publishing. > > In this way, we would be able to: > - load existing MC without problems > - publish new MCPackages that will be compatible with other dialects > > Indeed, Metacello configurations will need modifications, but we have a > smooth path to it. The Metacello configurations are still typically used only > for loading and that will still continue to work just like they do now. With > the Metacello Browser things will change, but then again we can change that > tool, too. > > The only problem is how to define class extensions. I believe the * magic > mapping is in MC. That will create problems, but for a while, I think we can > still rely on this mapping. > > Cheers, > Doru > > > > On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote: > >> >> On Mar 19, 2011, at 7:17 PM, Guillermo Polito 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... >> >> yes this is what cyrille started to do. On top of RPackage so may be >> cleaning that is the way to go. >> but the matching semantics is not good. >> >>> 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 >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > >
