[PD-dev] Proposals for object categories
matju at artengine.ca
Sat Feb 28 18:22:14 CET 2009
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
> 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
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
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
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
More information about the Pd-dev