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