On Mon, 19 Jul 2004, Frank Barknecht wrote:
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.
I can only second this thought. The rest of the topic has been discussed in and out.
The name clash problem does not only exist with externals but with abstractions too. There is a solution implemented in pd, which uses the filesystem and "/" as a delimiter between directory and external name.
Example:
/library/abc/foo.pd (on windows with "") /library/xyz/bar.pd
If /library is in your path, then you can load these abstractions with [abc/foo] and [xyz/bar]. The same applies if the two files are not abstractions but externals.
And here comes the big drawback. It will not easily be possible to load two externals of the same name, whatever namespace mechanism you implement, wether single externals or libraries. This would theoretically only work if the developers decide to name all of their ("exported") functions differently.
e.g the two "counter" examples:
both counters have "counter_bang" as their main function. You can not have two functions with the same name in a C program, so one of the counters will misbehave by using the wrong (first) counter_bang function.
The solution would be that the developers have to agree on function names, which brings us back to the initial problem.
What we really need is communication between developers.
If we do have the communication overhead, why shouldn't we decide on a single counter in the first place ? For the good of the user and the community ?
Guenter
PS: Or, even better, forget about having a counter external and implement the counter as an abstraction - but thats another story.