On Mon, 2 Jul 2007, Patco wrote:
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.
Actually it doesn't work like that. I made a mistake in the example. There are several namespace problems that are similar to the above, but none that is exactly that. It's the class that is loaded first that has precedence. When you have a locally defined object class, you can't use it with its local name without a prefix, because else the builtin class gets priority, or else any class that registered itself as having just that name will. This goes pretty much against the concept of namespaces of every language except Perl (in which class names have to be fully-qualified; other global things don't have to)
I vote for no namespace, no prefix,
You can't argue the case for no prefix at all ever. There are lots of reasons to use prefixes at least sometimes. What's debatable is when they should be used and why. (in this context, whenever namespaces act just like prefixes, they're effectively the same, so they are debatable in the same way as prefixes are)
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,
Here we are talking about class names at pd level. By putting the python class name as a 2nd or 4th element in the objectbox, Pyext bypasses Pd's own class naming mechanisms and also rejects the principle that no matter which language you use to extend pd, you can do essentially the same. Several other things break that principle: e.g. abstractions can't use variable number of arguments in their $-args. Pyext's class naming is another of them.
I believe that most other language interfaces allow direct registration of pd classes, but I haven't tried them and don't really recall. At least I can tell you that anything that is not an abstraction in GridFlow currently goes through Rubyext. (pd class registration ability in Ruby will not change, but which classes go through Rubyext will.)
I have never considered otherwise than direct class registration for any external language, and I'm kind of puzzled about why would anyone ever do otherwise. Anyway: I could show you a bit of C that creates an alias that redirect a certain name to [py python/myscript myclass]. Else there is supposedly the new sys_register_loader (pd 0.40) which can help with that; it would not have been required but Thomas decided to share Hans' exaggeration of the power of sys_register_loader.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada