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