[PD] pd extended development

Hans-Christoph Steiner hans at eds.org
Thu Apr 17 01:48:23 CEST 2008


On Apr 16, 2008, at 6:27 PM, Luke Iannini (pd) wrote:
> Python's namespacing has these features that I haven't seen  
> discussed yet:
>
> There are three common ways to import:
> "import list-abs", which just makes list-abs available for use, but
> you still need to type "list-abs.list-map" (the Python equivalent of
> [list-abs/list-map]). [1]
>
> "from list-abs import list-map", makes it possible to just type  
> "list-map".
>
> And finally "from list-abs import *", makes it possible to type any of
> the functions in list-abs without a prefix.
>
> The 3rd option is widely discouraged, because it makes it very unclear
> where a function comes from, or which one is in use.
>
> I greatly appreciate this arrangement, and I think it would be wise  
> to follow.

Those sound reasonable, but a lot more work to implement.  For the  
next release, there should be

- [list-abs/list-split] (like python without needed the "import list- 
abs" statement).  I am not sure I see the reason to have to import a  
lib in order to use it with the lib prefix.

- [import list-abs] which is the same as "from list-abs import *",  
for better or worse.  It's what Pd people are used to, so...

- I think it should be possible to do [import list-abs/list-split]  
but I haven't looked at it too much yet.


> A 4th feature that reduces verbosity is the ability to write "import
> list-abs as l".  And of course once things actually work, [list-map]
> could be renamed to just "map" to give [l/map], which I think is
> great.

This sounds like a write-only feature, it makes the code much harder  
for others to read.  If you don't recognize a library name, then you  
have to check both whether it is an alias, and if it is a library.   
 From what I have seen, aliases cause more harm than good in  
programming languages.

.hc

>
> Cheers
> Luke
>
> On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner  
> <hans at eds.org> wrote:
>>
>>
>>  On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
>>> Hallo,
>>> marius schebella hat gesagt: // marius schebella wrote:
>>>
>>>> Frank Barknecht wrote:
>>>>> Hallo,
>>>>> marius schebella hat gesagt: // marius schebella wrote:
>>>>>
>>>>>> sorry, I still don't know exactly what you mean. I think it is
>>>>>> the only
>>>>>> solution to keep libraries in subfolders if we want to solve
>>>>>> nameclashes. but even if in subfolders, they should be
>>>>>> accessible as
>>>>>> list-abs and not list-abs/list-abs.
>>>>>
>>>>> Huh? Nameclashes have nothing to do with subfolders per se. A
>>>>> nameclash
>>>>> is, when two objects have the same name registered in Pd but act
>>>>> differently. Folders are a way to organize files in a filesystem
>>>>> (harddisk).
>>>>>
>>>>>> the thing that I was complaining so loudly is that pd-extended
>>>>>> ships all
>>>>>> these libraries but does not add the paths.
>>>>>
>>>>> Yes, that's exactly what I mean: Many people would like every
>>>>> objectclass to be global.
>>>>
>>>> but that is not a problem for pd-extended users (and I want to
>>>> solve the
>>>> pd-extended problems here), as long as you can overrule the global
>>>> namespace with a local namespace.
>>>
>>> Not really: Say I use [urn] in Pd-extended. Which [urn] am I using?
>>>
>>> As pd-extended by popular demand (and for practical reasons) is
>>> configured to allow access to one of the [urn]s out of the box, I
>>> believe not many people are actually using the names [zexy/urn] or
>>> [maxlib/urn] or [cyclone/urn].  But all of these behave differently.
>>> So we have a hidden nameclash if you try to use a patch that assumes
>>> [urn] to be the one from the library, pd-extended loads as the  
>>> second
>>> one. Now IIRC Hans' goal is to not load any library or set any path
>>> out of the box, so that all names would have to be qualified with
>>> directory prefixes or [declare]d. But when this behavious  
>>> accidentally
>>> came into effect because of the change in plist-location on OS-X,
>>> people complained about missing objects and that their patches were
>>> broken with the new pd-extended.  Note that I don't want to rate if
>>> they complained for a good reason, I just want to point to a  
>>> problem.
>>>
>>>> pd-extended would provide a default object for every nameclash.
>>>> If you have old patches that were using objects, that are not the
>>>> default in pd-extended you would have to add a declare to your
>>>> patch. or
>>>> explicitely call them as mynondefaultlib/abs~.
>>>
>>> So you see: pd-extended selected a certain set of externals to be  
>>> the
>>> default set of available objectclasses in pd-extended. I don't know
>>> how it was decided which libs should be these defaults, I don't even
>>> know which ones are the defaults. Probably Hans just chose some
>>> popular ones, which is a sensible thing to do.
>>>
>>> In the long run, this process should become a bit more organized and
>>> it especially should not be handled along library/author  
>>> borders.  For
>>> example, I think, zexy (rightfully) has a high loading priority,
>>> because it's one of the oldest and most widely used library. But
>>> Cyclone also deserves a high priority because it's generally
>>> Max-compatible. OTOH zexy is older. What to do? If we only priorize
>>> complete libraries, we're not able to make finely grained decisions
>>> about single objects. Maybe zexy's [abs~] is better, while [urn] in
>>> Cyclone is preferable.
>>>
>>> In the end we may be back at square one: a "flatspace" with the
>>> selected best of the (un)pack objectclasses in a single  
>>> directory. No
>>> problems with path settings, all is fine again.
>>>
>>> Or what am I missing? ;)
>>
>>  The flatspace model breaks down when you start adding libraries  
>> to Pd-
>>  extended.  Then you can have nameclashes again.  Say someone writes
>>  their own library with an [urn], then what happens?  At best,
>>  confusion ensues.
>>
>>  If we look at other programming languages, we can see that  
>> namespaces
>>  are a very common  solution to this problem (C++, Tcl, python, Java,
>>  Smalltalk, etc).  I see no reason why it wouldn't work for Pd as  
>> well.
>>
>>  .hc
>>
>>
>>   
>> --------------------------------------------------------------------- 
>> ---
>>  ----
>>
>>  There is no way to peace, peace is the way.       -A.J. Muste
>>
>>
>>
>>
>>
>>  _______________________________________________
>>  PD-list at iem.at mailing list
>>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>




------------------------------------------------------------------------ 
----

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie







More information about the Pd-list mailing list