<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Happy 2018 list!!!<br>
<br>
IMO [foo/obj] is the “best practice”.<br>
<br>
@Christof<br>
I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.</p>
<p><br>
</p>
<img moz-do-not-send="false" src="cid:part1.F1114F48.6B6278B1@hotmail.com" alt="pic attached" height="407" width="406"><br>
<br>
<br>
--<br>
<pre class="moz-signature" cols="72">Mensaje telepatico asistido por maquinas.</pre>
<div class="moz-cite-prefix">On 1/2/2018 1:01 PM, Christof Ressi wrote:<br>
</div>
<blockquote type="cite" cite="mid:trinity-e57ac513-c4ca-404d-a331-0b7b4c979b11-1514908878780@3c-app-gmx-bs56">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr
Von: "Christof Ressi" <a class="moz-txt-link-rfc2396E" href="mailto:christof.ressi@gmx.at"><christof.ressi@gmx.at></a>
An: "Alexandre Torres Porres" <a class="moz-txt-link-rfc2396E" href="mailto:porres@gmail.com"><porres@gmail.com></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:pd-list@mail.iem.at">pd-list@mail.iem.at</a>
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" <a class="moz-txt-link-rfc2396E" href="mailto:porres@gmail.com"><porres@gmail.com></a>
An: "Christof Ressi" <a class="moz-txt-link-rfc2396E" href="mailto:christof.ressi@gmx.at"><christof.ressi@gmx.at></a>
Cc: "João Pais" <a class="moz-txt-link-rfc2396E" href="mailto:jmmmpais@gmail.com"><jmmmpais@gmail.com></a>, <a class="moz-txt-link-abbreviated" href="mailto:pd-list@mail.iem.at">pd-list@mail.iem.at</a>
Betreff: Re: [PD] declare vs. namespaces - current best practice
questions
2018-01-02 8:02 GMT-03:00 Christof Ressi <a class="moz-txt-link-rfc2396E" href="mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]"><christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]></a>: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 <a class="moz-txt-link-freetext" href="https://github.com/pure-data/pure-data/pull/205">https://github.com/pure-data/pure-data/pull/205</a>[<a class="moz-txt-link-freetext" href="https://github.com/pure-data/pure-data/pull/205">https://github.com/pure-data/pure-data/pull/205</a>] & <a class="moz-txt-link-freetext" href="https://github.com/pure-data/pure-data/pull/183">https://github.com/pure-data/pure-data/pull/183</a>[<a class="moz-txt-link-freetext" href="https://github.com/pure-data/pure-data/pull/183">https://github.com/pure-data/pure-data/pull/183</a>]
cheers,
happy 2018
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>