Hallo, Lex Ein hat gesagt: // Lex Ein wrote:
Hans-Christoph Steiner wrote:
Part of putting all of the code into a central repository
....like herding the sweetest, but most unwilling cats: not all developers will plant their code in the CVS.
For externals, the CVS already almost is a standard.
and also compiling all of the contributed objects as individual files
Unless I misunderstand you, this requires breaking up existing libs into separate objects. Lots of work, and the original developers won't want to do it, and won't want to touch it after someone's dismantled it.
Yes, this is a problem, and breaking up libraries only should be done as a last resort. But as shown by IEMLib technically it can be done and then it magically solves all nameclashes present in that library before.
Single externals are a solution, which works often (IEMLib) but not everytime (Gem, also I don't understand at all why Gem still has a "counter" object)
allows us to eliminate such conflicts.
No, that means you'll still have two different, say, "counter" single-entity libs and hence [counter], and users will still never be able to reach both of them.
The problem with libraries is, that you cannot disable an object inside a library, and you aren't aware, what objects are in which library. With single externals, everything is visible in the filesystem.
So if you use the packages (Debian, Windows, MacOS X), then there won't be conflicts if you don't use any libs.
Who will make the choice of which objects 'live' without renaming, and who 'dies' (gets renamed)?
We. The people on this list and on pd-dev and the CVS maintainers. It's just that we need to find a way to communicate or vote, which objects should be the standard "counter" or "prepend" objects.
I agree with you than some kind of namespace would be very useful, but it alone won't solve the nameclash problem, we also need socal enineering here.