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