On Sat, 28 Feb 2009, Luke Iannini wrote:
Do you or Marius have any concrete suggestions as to what wold be a better approach? You must at least admit things could be better, no?
Well, first, we need to realise what our values and tastes are. Then we can agree on a broad meaning of the word «better», contextually speaking. Then we can research possible solutions, and rate them in terms of their upsides and downsides. Eventually, when we have found a solution that is more better than it is worse, I can admit things could be better. Until then, there is only hope and cheerleading. Well, that's already a good thing and it's very important in order to get things moving; but having a fact in your hand and being able to _admit_ it, now this is some kind of achievement.
I just took a look at Max/MSP and they have a nice tagging system,
I do support tagging rather than mutually-exclusive categories. I won't bother looking at Max/MSP's tagging system though. If there's anything in it that people really want, I'll hear about it.
Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
Not necessarily that way. They could be there, but they could also be in a file reserved for that purpose. That would be much faster to load and wouldn't require a cache, but that's not the main reasons. It would be quicker to have an overview of a whole library (or of the whole system) by looking at a single file, and quicker to edit it as well. It's also better to at least allow tag files outside of the library packages themselves, and allow them to superimpose transparently to packages' tags, because then you can have user-defined tags (a user's way of taking notes) and at the same time a package can upgrade its own tag files without interfering much with the user.
A good bit of work there though, and it doesn't do anything for namespace issues, just ease-of-discovery.
Alas, even namespaces don't do much for namespace issues. Look at how, for example, Java Swing got its namespace done. You have to import Swing, and then nearly everything in it has a J prefix to it. Why? Because namespaces are largely ineffectual. You put enough classes in the same namespace so that you don't have to write too many import-directives. Then you do use the import-directives to put together the combination of libraries that you will use to do something. As things that we do get more complex, more libraries are needed at once. Eventually, you get a clash anyway. I still agree that there are less clashes with namespaces than without, but they seem to be a lot of effort for the amount of payback.
Tags don't all have to do with ease-of-discovery. They can be used to simplify the documentation itself, as for example any class tagged "stdinlets" has one hot inlet and N cold inlets that work the usual way, and "stdoutlets" is likewise a shortcut to not have to explain that a class sends out on all of its outlets at once, right-to-left, like [unpack] does. This tagging concept can cut significant amounts of documentation in a way PDDP never quite envisioned.
Furthermore, tags can also be used for automatic testing, as for example, if a class has the stdinlets or stdoutlets property, that is something that can be verified. This can be used to generate a wrapper-abstraction for a class, that would check anything about a class that can be reasonably checked automatically, so that when you are using the class through the wrapper, the wrapper is continuously checking that the tags are correct (for any tags that have specific tests associated to them).
Furtherfurthermore, tags can also be used for design. If the automatic tests are already associated to tags, then those tags get to shape the design of classes, as we try to make classes conform to tags, compress the documentation by making it use tags more, and keep the number of different tags low so that tags stay useful and easy to browse through.
But, I also do not think that the difficulties you guys are enumerating are enough to condemn the entire idea of organizing things more logically than by author. I can at least offer Python as example of an extremely well-organized set of libaries - I don't know the history of /how/ they came to be that way but i can easily "import functools, urllib, os, simpleosc, midi, Image, pickle", and it works phenomenally well.
But what nameclashes does it fix? I mean, you could also have a Python that tries doing away with imports, would load anything on demand, and then, what would the nameclashes be?
A major difference between something like Python and something like Pd, is that in the former, classes already act as a namespacing device, and methods tend to be many-per-class. In the latter, however, classes don't tend to be used as such, the methods are few-per-class (e.g. left-inlet has float, set, bang, right-inlet has just float), so the role of a class in Pd is closer to that of a method in Python, and thus you have a much greater proliferation of classes in Pd for the same amount of functionality.
So, would it be the case that making Pd's namespaces like Python's would make Pd's namespaces really feel like Python's?
Namespaces are this strange beast: the more nameclashes would be possible, the more nameclashes are solved by namespaces, but the more nameclashes happen anyway because of conflicting imports, so in situations where you just don't want to see any clashes at all (an all-or-nothing proposition), there's not so much middle-ground in which namespaces both really address a problem (nameclashes would be possible) and successfully so (nameclashes are all resolved).
On Feb 27, 2009 at 3:58 PM, Mathieu Bouchard <ma...@artengine.ca> wrote:good/ bad/ ugly/
note that there is really a programme that uses those categories in the package management: GStreamer.
easy/ normal/ difficult/ expert/ ninja/
I wrote this because of the tendency of graphical-user-interfaces (outside of Pd) to have an "advanced" section, in which all the important things are. (All the other important things are, of course, removed from the UI completely, as they could "confuse" the user).
lime/ strawberry/ blueberry/ grape/ tangerine/
When the G3/333 iMac came out, choosing a computer had never been that superficial. It hasn't really been ever since.
country/ western/
When I was a kid, in my hometown, bars played *both* kinds of music. Nowadays, thanks to cataclysms such as illegal fishing and Brigitte Bardot, my hometown had to recycle in tourism and open itself to slightly more diverse bars...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
