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" <[email protected]> > An: "Alexandre Torres Porres" <[email protected]> > Cc: Pd-List <[email protected]> > 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" <[email protected]> > An: Pd-List <[email protected]> > 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 > <[email protected][mailto:[email protected]]>: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 > > > > _______________________________________________ > [email protected][mailto:[email protected]] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] > _______________________________________________ [email protected] mailing > list UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
