Mathieu Bouchard a écrit :
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?
Thanks to make 'what namespace is' clear.
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 vote for no namespace, no prefix, it's difficult enough to organize files for pd, and many prefixes won't work with externals that requires a script, for example if I put my python scripts into extra/python, I'd call the script with [pyext] with a namespace like that [py python/myscript myclass] but obviously it won't work, in fact I'd have to start pd with -path python or put the script into the patch's folder and put no namespace for the script file reconized, same thing with tcl scripts, etc... I'd add that a good taxonomy should take into account any pd and external related files.