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