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 <siguctua@gmail.com> wrote:
On 14 March 2013 08:00, Tudor Girba <tudor@tudorgirba.com> 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"