2018-01-04 18:41 GMT-03:00, Christof Ressi <christof.re...@gmx.at>: >> (is there a difference in behaviour between them?) > > stdlib is relative to the 'standard paths' whereas path is relative to the > current patch. > > my point is that the user could have their libraries in a totally different > place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will > work.
I see, but this is kinda parallel, and we're currently discussing changes to how the path works, as I referred to in the links I sent before. What I'm just questioning is wether using [declare] will force and avoid name collisions. I went ahead and made a test to make sure if what I said actually happens. So, I created a dummy abstraction named gate, put it inside a library that is listed in the path’s preferences, then I took cyclone out of the listed paths. Then what happens when I call [gate] is that it finds this dummy abstraction instead! Now, what I did next is I added [declare -path cyclone] (no -stdpath) and [declare] now forces it to find [gate] from cyclone instead. So, yeah, this is what I said it’d would and should do, so I checked and it does happen for me. Therefore, using [declare] will avoid name collisions and not the opposite. cheers > > Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr > Von: "Alexandre Torres Porres" <por...@gmail.com> > An: "Christof Ressi" <christof.re...@gmx.at> > Cc: pd-l...@mail.iem.at > Betreff: Re: Re: [PD] declare vs. namespaces - current best practice > > > 2018-01-02 12:37 GMT-03:00 Christof Ressi <christof.re...@gmx.at>: >> >> what do you mean by [declare cyclone]? >> >> in case you mean [declare -stdpath cyclone]: > > > I meant adding a library as path or a lib, either in -stdpath / -path / > -stdlib / -lib (is there a difference in behaviour between them?) > >> >> a) this would only work if cyclone is in the user's stdpath (which you >> can't know as a library writer) > > > why? > >> >> b) it only adds the cyclone folder to the search path. writing [gate] is a >> gamble because iemlib could be earlier in the search path (or the single >> binary library could've been loaded). >> >> >> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr >> Von: "Alexandre Torres Porres" <por...@gmail.com> >> An: "Christof Ressi" <christof.re...@gmx.at> >> Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at >> Betreff: Re: [PD] declare vs. namespaces - current best practice >> >> questions >> >> 2018-01-02 8:02 GMT-03:00 Christof Ressi >> <christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi, I think in your >> case you shouldn't need [declare] at all. [declare -stdlib somelib] makes >> the assumption that 'somelib' is installed in one of Pd's standard paths. >> This was maybe true for Pd extended where all libraries were in the /extra >> folder but actually it could be any other folder (which the user added to >> their search paths). >> >> IMHO, best practice is to explicitly list your dependencies and have the >> user set them up correctly. >> >> regarding namespaces: >> >> In an abstraction library I would always use them if I can (unfortunately >> it's not possible with externals which are part of a single binary >> library). It eliminates the possibility that a wrong abstraction/external >> is called. My favourite example: >> Say that for some weird reason you're using [gate] from cyclone. If a >> users happens to have iemlib earlier in their search path, all your >> abstractions will have iemlib's [gate] object instead - which works >> exactly the other way around! This actually happened to a friend of mine >> :-D. >> >> won't [declare cyclone] force a priority of it over iemlib? If not, >> shouldn't it? >> >> now, for related discussions on declare/standard paths, >> see >> https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205] >> & >> https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183] >> >> cheers, >> happy 2018 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list