On Sun, 1 Jul 2007, Thomas O Fredericks wrote:
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/Llanfairpwllgwyngyllgoger...
http://www.websterlakeassociation.com/images/Cropped%20Thompson%20Road%20sig...
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