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.
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.
Cheers Luke
On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner hans@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list