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" <[email protected]>
> An: "Alexandre Torres Porres" <[email protected]>
> Cc: [email protected]
> 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" <[email protected]>
> An: "Christof Ressi" <[email protected]>
> Cc: "João Pais" <[email protected]>, [email protected]
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> questions
>
> 2018-01-02 8:02 GMT-03:00 Christof Ressi
> <[email protected][mailto:[email protected]]>: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
>
> _______________________________________________
> [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
