On 14 March 2013 08:00, Tudor Girba <[email protected]> wrote: > Hi, > > When we started with RPackage there was a debate as to the strategy regarding > the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it > seems this is what we now have. > > The detailed plan looked as follow: > > --- > Stage 1: Get RPackage in the image and pretend that it acts like a smart > cache for categories. Everything is expressed in terms of categories and > mirrored in RPackages. Tools can now be built on top of RPackage. At this > stage, no modification is needed and the new tools will work next to the old > ones. > > Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 > Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on > 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to > start changing the configurations. >
.. and rewriting a working code. Why i cannot have 1 package with 2 categories 'Foo-Core' and 'Foo-Core-Bar'? Why we need such requirement? why developer cannot choose what categories going into package? Now i will be forced to fold all classes back into single category if i want to not end up with 20 little packages (which cannot be loaded, btw , because of dependency ..) To reflect, how bad it sounds to me, let me propose different publishing order: - all classes with same first two letters in name should go to same package. Do you like it? No? Not matters.. we will force you to obey to it, starting from tomorrow. > Stage 3: Change the Monticello loading to only allow 1-to-1 > RPackage-to-MonticelloPackage. At this point, we can safely remove the > Categories. > --- > > Now we passed Stage 1 which is great. At this point, everyone can work like > before, but are encouraged to create explicit Monticello packages out of > categories. Next, I would like to propose that for Pharo 3.0 we go for Stage > 2 and modify slightly Monticello publishing. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Quality cannot be an afterthought." > > -- Best regards, Igor Stasenko.
