Le 06/06/2015 14:57, Sergio Fedi a écrit :
So getting back to Pharo's tags, I like the fact that there are some common namings, such as many packages will have tags like "Examples", or "Tests", however I still fail to see why would you want to put one class into multiple tags and what the benefit would be.
In my case I have a hard time dealing with hierarchical categorizations, I haev plenty of aspects of my code that runs accross in different ways.
One case is the Model/Web/Application vs Tests, which they can be combined orthogonally.
Another aspect is that I have classes that belong to different layers: Application, Interface-Web, Interface-Windows, Interface-CommandLine, Commands, Model, Persistence But them several of these classes belong to different "modules" or sets of functionality: Clients, Providers, Administration, Production
With a Tag scheme, I can arbitrarily browse:
All commands that are in the Provider module Persistence Tests Classes from Production and Persistence (which should be empty)
At the moment, tags are a bit strict (i.e. hierarchically included with packages) because of their relation with system categories (one per class). But elsewhere in the system (i.e. packages) they aren't that significant (for example, they don't appear in packages). So, we could do what you say (allow for multiple tags to a class) in a compatible way with system categories with a slightly different syntax (and some changes to RPackage): a category of: PackageName-Interface/Windows Would say that those classes belong to tags Interface and Windows The system browser could just then either parse the category (split by $- for the package name, then split by $/ to get multiple tags) or rely on RPackage to do so. Thierry