[PD] declare vs. namespaces - current best practice

Lucas Cordiviola lucarda27 at hotmail.com
Tue Jan 2 19:34:10 CET 2018


Happy 2018 list!!!

IMO [foo/obj] is the “best practice”.

@Christof
I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.


[pic attached]


--

Mensaje telepatico asistido por maquinas.

On 1/2/2018 1:01 PM, Christof Ressi wrote:

the current situation with namespacing is a bit unsatisfying. let's assume there are libraries 'foo' and 'bar' which both have an object called 'obj'. if both are multi-binary libraries then both objects can be created with [foo/obj] and [bar/obj]. this doesn't work, however, with single-binary libraries. you have to write [obj] and if library 'foo' is loaded first, 'obj' from library 'bar' can never be created.

a solution could be to encourage library writers who favor the single-binary style to add creators with the library name prepended, like

obj_class = class_new(gensym("obj"), (t_newmethod)obj_new,
                          (t_method)obj_free, sizeof(t_obj), 0, A_GIMME,  0);
class_addcreator((t_newmethod)obj_new, gensym("foo/obj"), A_GIMME, 0);

so users have a chance to deal with possible name collisions.

IOhannes did this in zexy with [zexy/pack] and [zexy/unpack] (for slightly different reasons), that's where I got this idea.

having no real namespacing for single-binary libraries is actually a bit crazy, given the very generic names of many objects.




Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr
Von: "Christof Ressi" <christof.ressi at gmx.at><mailto:christof.ressi at gmx.at>
An: "Alexandre Torres Porres" <porres at gmail.com><mailto:porres at gmail.com>
Cc: pd-list at mail.iem.at<mailto:pd-list at mail.iem.at>
Betreff: Re: [PD] declare vs. namespaces - current best practice

what do you mean by [declare cyclone]?

in case you mean [declare -stdpath cyclone]:
a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer)
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><mailto:porres at gmail.com>
An: "Christof Ressi" <christof.ressi at gmx.at><mailto:christof.ressi at gmx.at>
Cc: "João Pais" <jmmmpais at gmail.com><mailto:jmmmpais at gmail.com>, pd-list at mail.iem.at<mailto: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]><mailto: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

_______________________________________________
Pd-list at lists.iem.at<mailto:Pd-list at lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list




_______________________________________________
Pd-list at lists.iem.at<mailto:Pd-list at lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180102/950e0444/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib1.jpg
Type: image/jpeg
Size: 40102 bytes
Desc: lib1.jpg
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180102/950e0444/attachment-0001.jpg>


More information about the Pd-list mailing list