[PD] pdmtl abstractions questions and comments

[Mathieu Bouchard]

On Sun, 1 Jul 2007, Thomas O Fredericks wrote:

> T: In the http://wiki.dataflow.ws/PdMtlAbstractions/Usage

Ok, thanks for the link, I don't know why I didn't see that.

> a) abstractions that finish with "_~" are graphical signal objects

Ok, but I don't think that the "_" character is so distinctive. I mean, 
it's enough to distinguish unambiguously, but it's still looks pretty 
close to a space, and it doesn't seem to have the kind of appeal to it 
that ~ has by looking like a wave or # has by looking like a grid 
(GridFlow was using @ before, and the mnemonic was less obvious). Perhaps 
that the ascii code offers too few characters and using unicode is too 
weird; then I'll concede that if you believe that there has to be a 
single-char suffix, underscore is not a bad choice at all.

> T: Although I prefer abstractions without a "-" or a "_" in their names, 
> others do not. But, since our wiki states that "class names with 
> multiple words in the name should use underscores to separate words

Ok. Perhaps the problem is that some people's conception of words is 
different. Witness:

http://upload.wikimedia.org/wikipedia/en/5/5b/New_Zealand_0577.jpg

http://en.wikipedia.org/wiki/Lopado...pterygon

http://upload.wikimedia.org/wikipedia/commons/e/e8/Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch_station_sign_%28cropped_version_1%29.jpg

http://www.websterlakeassociation.com/images/Cropped%20Thompson%20Road%20sign_0008.jpg

> this follows the http://puredata.info/docs/developer/CodeGuidelines

Ok, I don't particularly remember reading them back when they were posted. 
Now that I read them I'd like to say that the part about namespaces is 
quite bad: if I make a more descriptive name for a class that is really a 
lot like [poil], it would be something that ends in "_poil". However this 
means that a prefix is added to the name. The same section says that 
prefixes are to be turned into geiger namespaces, that is, folders. Let's 
say that the folder is named "patate". But then I cannot use the original 
[poil] anymore in that folder because pd picks up the locally defined 
[patate/poil] as being poil itself, hiding the prefixless [poil] that I 
need. Therefore a prefix is required. Then I might call it 
patate/patate_poil.pd, but that's redundant, so I remove the folder so 
that it's just called [patate_poil], and then we're back to prefixes. 
However if pd wasn't doing that and if there wasn't [import] then the 
slash wouldn't be anything more than a tilted underscore. So what are 
those guidelines good for?

> All abnormal abstractions will be renamed (thanks a lot for the work Mat 
> :)

(What are you talking about?)

> M: "I think it's pretty standard that every *-help.pd file has to
> contain an object of the class that it documents. Breaking this rule
> by cutting the documentation into that and *-example.pd files seems
> pointless.
> T: This is probably an oversight, please give examples of the
> erroneous help files.

Actually there's only one *-example.pd file that I can see in 2007-05-29, 
it's init/at_parse-example.pd. (I haven't done an svn checkout and for the 
previous mail I was using the web interface of svn.)

> The "synth" folder groups abstractions that are more like "complete" 
> "midi" instruments (or at least try to be). Think of the "generate" 
> category as the building blocks for the "synth" category. If this still 
> seems to confusing, please reply with an alternative.

You mean alternative names or a solution along the lines of splitting the 
concepts? I don't even understand the concepts. I'd be glad to use some of 
the stuff in "generate" as "complete" instruments, if I was still 
composing any music, but else I know composers who'd do exactly that.

> If you still find it confusing, where should we move the abstractions 
> from the "transform" category?

Why not put stuff outside of categories? (Does everything have to be in a 
category?)

> T: The problem is that in any programming environment 99% of what you
> are doing has to do with math. The basic principle behind the
> categories where to think of them more as verbs, actions or types,
> instead of categorizing stuff along the c standard (or whatever it
> could/should be called).

uh, what's that "C standard" that you are talking about? I don't think 
that C standards says anything about the use or non-use of verbs in 
function names. If you're thinking about something else then you'd have to 
tell me whose convention it is so that I can find what its rules are so 
that I can see how it contrasts with your way. Perhaps a Kernighan&Pike 
book has something to say about that, but I never read those, just flipped 
some pages a bit.

> The verb, action or type categorization method tries to follow the 
> dataflow method. For example, swap, print, send, receive, select, route, 
> pack, etc are all verbs.

bang, float, symbol, int, spigot, moses, value, metro, line, timer, 
cputime, realtime, pow, mtof, random, ... there are lots of nouns as 
classnames in pd too. Where it's ambiguous, I count a word as a noun if 
the verb wouldn't be a good description of what happens. e.g. "to line" 
isn't like [line], so i counted line as being noun; but [delay] makes 
equal sense as "to delay" or "a delay", so I'd count it as being either 
both or neither.

There's no agreement on the use of noun vs verbs at the level of pd/max 
and even less at the level of all dataflow things. So you can't really say 
that there's a "dataflow" way of naming things.

In regular (non-dataflow) object-oriented programming, there is that 
concept that classes are nouns, vs that methods are verbs, but some people 
take it too seriously, to the point that it gets cumbersome: you wouldn't 
send a message "duration $1" because it's a noun, it would have to be 
called "set_duration $1". That's the Java style. The Ruby style is that 
just because methods have verb-like properties doesn't mean that they have 
to map to English verbs, so it would be called "duration= $1", where = is 
the suffix meaning "to set" on a noun, whereas no suffix would mean "to 
get". (in pd, emphasis is on setting, so "to set" is the expected meaning 
of a lone noun for a method name).

> "math" is more of a category for stuff that hasn't found it's proper 
> place yet. What do you think?

I think that category names have to be figured out pretty quick if people 
are expected to start using the names in backwards-compatible ways. Else 
you get into what is called "bit rot" - a program is not just the contents 
of source files, it's also a set of relationships with its environment, 
and especially, its direct dependencies.

> Should the "number" category be include in "math"? How about 
> "scale","random" or "anal".

I don't know. We could have a head-scratching party in my apartment, if 
you'd like some brainstorm about it. I didn't speak much when you made 
that presentation of pdmtl abstractions because that was my first exposure 
to it so I had to think about it a bit.

> Tags instead of categories would be much better.

If you mean that there wouldn't be namespaces and instead there would be a 
non-arborescent taxonomy whose purpose would still be to organise similar 
objects together documentation-wise, then I would say that I agree.

> M: " _index.pd files don't actually contain a list of the patches in the
>    folder, so why is it called an index?"
> T: You are obviously not using either of the official pdmtl
> abstractions help browsers ( hbrowser.pd or hpopup.pd) as they
> automatically exclude all files that they consider are not help files.

I'm using /usr/bin/ls or the svn web interface. What's wrong with either? 
I'm obviously not asking this as a simple user.

> So what is "_index.pd" for?

Uh, my question actually is "why is _index.pd called an index?".

> T: Hum, so you asking us why we did not include a "mapping" category
> and then comment that "mapping" useless or too general???!!!

Yes... if you don't understand the logic of it, then I don't know what I 
can do... I'd rather raise the issue before the category is even created. 
I didn't pick "mapping" as a random victim either: it's specifically 
because Alex had previously asked me questions about making abstractions 
in the style of HCS's "mapping" library, and that got me quite puzzled, 
like, why one would actually want such a library in the first place, etc.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada