edit: [declare] can (and is) also effectively used as a kind of C++ using directive or python wildcard import - which is sometimes useful but nonetheless eliminates namespacing.
Gesendet: Samstag, 06. Januar 2018 um 11:53 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Alexandre Torres Porres" porres@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
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 ;-)
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?
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") Christof
Gesendet: Samstag, 06. Januar 2018 um 04:04 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
ok, that changes things a bit. It is still true that [declare] will prioritize to first load an object from that specified lib (let's call it lib1), even if there's another one (lib2) with the same object listed in the path. But this only happens if none of these objects have been called before. So this is still safe if you're sharing a patch to be first opened on its own. Now, things get hard to control if you've forced to load the object from lib2 beforehand, then try to load the other one from lib1 without a prefix and trying to rely on [declare]. But this also depends wether it is an abstraction or not, and, as I see it, that is inconsistent behaviour. Not only that, but I could also ask wether this is more of an issue on how Pd handles the object search than how [declare] works. And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it? I would assume that's what it had to do. cheers 2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at]>:On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called, and the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
fgamdsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list