On 19 March 2011 15:53, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 March 2011 08:11, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.
Or, since you doing new environment-tied browser, you can say to single browser instance: please stick with this package, and for another instance - stick with another. Then anything you do in browser goes to these package(s).
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.
-- Best regards, Igor Stasenko AKA sig.