Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
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?
Actually that is why I didn't yet use directory prefixes for my abstraction libraries, especially the [list]-abs. Without their prefix -- [list]-abs is using a dash instead of an underscore or a slash, because underscores are harder to type on german keyboards and because not following guidelines leads to more fun in life --, objects like [list-abs] or [list-moses] are impossible to use in Pd anyways, as [abs] and [moses] are builtins.
So a prefix directly in the object name is necessary. "list-" to me looked like the most natural choice - and it doesn't need "Shift" on german keyboards to type, so I was set.
The choice of pdmtl was "list/". Another good and obvious choice, but to me it doesn't really have any advantages over "-" (and needs "Shift" on german keyboards...) Unless you stick to unused names only, you always need to keep the prefix in the object name.
If someone else does an abstraction collection for lists, I'd say, "list_" or "list." are two other good choices.
Where directory prefixes shine however is for making packages of externals and abstractions. Pd-extended is the prime example: It can ship all five [counter] objects, which would be impossible without subdirectories for each collection. Whether shipping five counters is desirable is debatable, but at least people have a choice.
However shipping objects (or classes, as you suggest to call them) in subdirectories creates a possibly uncomfortable side effect: It introduces an additional, possible prefix: the directory name. So people start to use objects called [list-abs/list-abs] just because for packaging reasons, list-abs.pd in pd-extended lives in a directory called "list-abs". Now that's what I call redundancy: Instead of one, we get two prefixes. At least my help-files still work.
pdmtl may face a similar or worse problem when people start using objects with names like [pdmtl/list/op]. Here not only help-files will be broken, as the help file "list/op-help.pd" uses an object called [list/op] which is unavailable unless "pdmtl" is in the path. Actually all objects using [list/x]-objects are broken then!
To somehow be prepared for that pdmtl would need to use [import] or [declare -path ..] in every abstraction, and take note, that [declare -path ..] will also activate all other subdirectories of ptmtl for that patch - mostly this won't be a problem.
All this to me seems to kind of pervert what Guenther Geiger actually intended when suggesting directory prefixes and initiating the CVS-repository. Instead of shipping five [counter]s, one [counter] would be shipped as the default [counter] directly in extra, other counters would be hidden in subdirectories for special use, but be deprecated. The reality now is, that [flatspace] announces that it is deprecated, and the "Path" window is filled with more entries than it can handle.
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.
[list-abs/list-abs] is bit-rot.
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.
I had to look up arborescent, after that I agreed, too.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__