So I will check to see what can be done but it looks painful. Stef
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.
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
As i suggested, we should not rely on category naming in new packages at all. I think we could create an importer which using a legacy logic of making classes belong to some package based on their category name.
Yes but this is a pain. :)
In future that should be removed.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.