Ok!!!! I love these examples. I thought that by mapping you meant mapping submatching categories
> > I do not want to select the RPackage that maps to an MCPackage. This should > be done transparently by the tool: 1 Category maps on 1 RPackage and this > maps on a potential MCPackage. > > Let's take an example. You load the original MCPackage Foo: > > Foo > Foo > Foo-Bar > > We get 2 RPackages: Foo and Foo-Bar. > We add a new RPackage Foo-Zoo. > We open the NewMCInterface and we get three MCPackages: > Foo > Foo-Bar > Foo-Zoo > > The Foo-Zoo MCPackage is offered without any explicit creation. Like this you > take away the extra step and you control the mapping in the way you want. > > Cheers, > Doru > > > On 20 Mar 2011, at 10:04, Stéphane Ducasse wrote: > >> Thanks doru. >> I will digest that. I have the impression that I understand your approach >> but would not it be error prone to select the Rpackages you want to map to >> MCPackage? >> >> Stef >> >>>>> 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. >>>> >>>> this sentence is not clear doru. >>>> Do you mean that a RPackage should contain classes that are contained in >>>> matching PackageInfo package? >>>> I mean >>>> RFoo >>>> contains RFoo and RFoo-zork categories classes? >>> >>> No. I meant we have a 1-1 mapping to categories. So, you will get multiple >>> RPackages in the system: RFoo, RFoo-zork ... >>> >>>>> 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. >>>> >>>> The problem is not publishing the problem is assigning classes to >>>> packages. >>> >>> I think that if we split loading and publishing logic as a transition phase >>> it would solve the problem, and I actually believe that you are talking >>> about a similar thing (see below). >>> >>>>> In this way, we would be able to: >>>>> - load existing MC without problems >>>>> - publish new MCPackages that will be compatible with other dialects >>>> >>>> let us see >>>> imagine the following scenaro >>>> >>>> PI-Foo contains >>>> Foo >>>> Foo-Zork >>>> >>>> => >>>> We get >>>> RFoo >>>> and RFoo-Zork >>>> >>>> we can save and people can load >>>> now >>>> >>>> I add a category Foo-Two >>>> in pharo I get an extra package >>>> we should modify metacelloConfig >>>> ok people can load it too >>>> >>>> in other system it will be in Foo >>>> ok we can load it >>>> >>>> >>>> Now if we should preserve the current loading semantics **package >>>> creation** >>>> >>>> when PI-Foo contains >>>> Foo >>>> Foo-Zork >>>> >>>> if we should create only one RFoo containing all the FooCat >>>> then we arrive to the point where this is not clear that >>>> when I add a new cat it will not be in. >>> >>> The solution I proposed was a new publishing interface for MC that works >>> with the 1-1 mapping between RPackage and PackageInfo. Like this, for >>> saving we would be force to save the new package. >>> >>> So, in your case, when you would open the NewMC, you would see in the list: >>> >>> Foo >>> Foo-Zork >>> Foo-Cat* >>> >>> The +Package button would disappear altogether. You would be provided with >>> the possible things to commit, and then you would not have to think about >>> the mapping at all. All you have to do is select each of the RPackages that >>> you want to commit, and if there does not exist a correspondent Monticello >>> package for it, you would be asked to provide the repo and then the >>> creation would happen transparently. >>> >>>> So we could always load and create a RPackage for each Category. This >>>> would be simpler. >>> >>> In your solution, you would again split the mapping logic of load from that >>> of publishing but you would change the loading mapping such that when you >>> load you create only one category per PI. Perhaps that is indeed simpler, >>> but you would lose the extra info of categories. >>> >>> >>> Were my explanations clearer now? >>> >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> >>>>> 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. >>>> >>>> yes >>>> >>>>> >>>>> 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." >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every now and then stop and ask yourself if the war you're fighting is the >>> right one." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > >
