________________________________________ De : [email protected] [[email protected]] de la part de Stéphane Ducasse [[email protected]] Date d'envoi : samedi 8 septembre 2012 08:53 À : [email protected] Objet : Re: [Pharo-project] RE : RE : RE : RPackage, Monticello and the removal of PackageInfo
> No they are layered. > > Monticello > RPackage > > and not the inverse. They should be, you mean. In practice, they are not layered like that. > We would not need tags with this scenario. > In scenario 2 RPackage are first class categories handling class extension. Ok. I would like more to call them RGroup, then :-) > I do not think so. > This is just that we decided to be backward compatible. > Personnally I would have just throw away categories. We do not need them. > But we are like poor people wanted to be rich, we do not have the money but > we want more stuff. :-) I want that too. >> There is also a body of adding additional hierarchy levels in MCPackages by >> carefully naming packages with well chosen prefixes and - (System-whatever >> for example), which points out to the fact packages developpers need at >> least one more level of hierarchy. > This is why in the first design we added tags. But tags would have worked inside todays MCPackage, not when multiple MCPackages are grouped together via a common prefix. And even then, it's too much. To make the base system understandable, I added two additional levels on top of the MCPackage. > I think that we should let esteban experiment and we will discuss again to > see. > Frankly I do not like the pattern-matching semantics and I understand that we > do not want an explosion of packages > so let us give a bit more time and see. But could it be possible then to make the current one as stable as possible, to see if it can be made viable (and help correct bugs in both?). Moving a RPackage-based tool from RPackage+tags to RPackageSet + RPackage should not be too hard, once settled on a design choice (and trying to keep more or less the same API). Thierry
