[PD-dev] Proposals for object categories

[Mathieu Bouchard]

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 <matju at 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