[PD] pdmtl abstractions questions and comments
matju at artengine.ca
Tue Jul 3 16:55:12 CEST 2007
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
More information about the Pd-list