[PD] pdmtl abstractions questions and comments

[Mathieu Bouchard]

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