Yes I would love that. I'm concerned about the migration from current situation to the new ones. Stef On Mar 19, 2011, at 11:28 AM, Marcus Denker wrote:

On Mar 19, 2011, at 8:12 AM, Stéphane Ducasse wrote:

...

...

Is this a conscious decision to have an unique package per each category name, or just a technical limitation?

RPAckage has nothing to do with category matching: a package is a list of classes and methods.

Now the problem is simply the following:

you have a MC package FOO it contains FOO-Cat1

you load it: ok the loader could create RPAckage Foo and put FOO classes and Foo-Cat Classes in it

Now you create a new category FOO-z what should I do add it to FOO create a package Foo-z

We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.

Imagine we would at the same time abandon both PackageInfo *and* System Categories.

Then you would just do:

you have a MC package FOO it contains FOO-Cat1

--> One RPackage Foo

you have a MC package FOO it contains FOO-Cat1 FOO-Dog2

--> One RPackage Foo. We loose the sub structure.

For the sub-structure, the way categories are now used in PackageInfo packages is that they do not denote sub-packages, but just some convinient sorting without semantic (to the language) meaning, just as method categories.

So the perfect thing would be to have some form of ordering inside of RPackage (e.g. tagging).

The case "Now you create a new Category" would not exist, as there are no categories anymore. Categories should die.

Marcus

-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.