>
> 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.
>
>