2018-01-06 7:53 GMT-03:00 Christof Ressi <christof.ressi@gmx.at>:

> So this is still safe if you're sharing a patch to be first opened on its own.

in other words: it's not safe at all ;-)

why not? If you first open Pd with a patch that uses [declare], from someone who shared it, it'll be guaranteed that it works! Given that you have the library, of course...

> And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?

I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.

imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?

you can't, you can only do that with namespaces, alright, but this is still a pretty specific use case, and I don't understand what it has to do with the idea that [declare] should force a priority, which is something it actually already does as I pointed out...

and ok, it doesn't always do that as we discussed and found out, but then it's just a matter of "fixing" it...

namespacing by definition involves some kind of extra typing (like it or not) to differentiate entities that otherwise would look the same. the current mechanism of prepending the folder name already supports that, only single-binary libraries are sometimes a problem. cyclone already shows how this can be dealt with effectivly by adding a second creator (e.g. "cyclone/gate")

cyclone doesn't have a second creator for "cyclone/gate". It is not a single-binary library, but a mix of things, it has a) abstractions, b) separately compiled objects and c) a single-binary sub pack. For "c" - which is a library named "cyclone" (that loads non alphanumeric objects) - we have a second creator, so, given that you first loaded the "cyclone" (with declare or whatever) you can load an object like >~ as either just [>~] or also as [cyclone/>~].

This way you can force namespaces into single binary packs.

cheers