On 19 March 2011 08:11, Stéphane Ducasse <[email protected]> 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. > No. The process should be different:
You marking an active package (in same way as currently we having an active changeset). Then anything you do (any classes or methods you creating) is going straightly to that package. Now, what to do if you hacking around or do refactoring over multiple classes in multiple packages: - you can say that for the time of your hacking session a methods you changing/adding should belong to same packages as their classes (instead of adding methods to single active package as extensions). This should be default behavior. > >> 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. >> -- Best regards, Igor Stasenko AKA sig.
