[PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-04 18:41 GMT-03:00, Christof Ressi <christof.ressi at 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" <porres at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-list at mail.iem.at
> Betreff: Re: Re: [PD] declare vs. namespaces - current best practice
>
>
> 2018-01-02 12:37 GMT-03:00 Christof Ressi <christof.ressi at 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" <porres at gmail.com>
>> An: "Christof Ressi" <christof.ressi at gmx.at>
>> Cc: "João Pais" <jmmmpais at gmail.com>, pd-list at mail.iem.at
>> Betreff: Re: [PD] declare vs. namespaces - current best practice
>>
>> questions
>>
>> 2018-01-02 8:02 GMT-03:00 Christof Ressi
>> <christof.ressi at gmx.at[mailto:christof.ressi at 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