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