Hi Igor, Please, let's keep the discussion at the level of arguments.
The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism. At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage. The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this. Perhaps there are other options, too. Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :). Cheers, Doru On Thu, Mar 14, 2013 at 8:26 AM, Igor Stasenko <[email protected]> wrote: > 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. > > -- www.tudorgirba.com "Every thing has its own flow"
