[PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-06 13:35 GMT-03:00 Lucas Cordiviola <lucarda27 at hotmail.com>:

> I steel believe that the “best practice” is [foo/obj]. At least for
> sharing patches. At home or with live-patching is another story.
>

I've been responding to this thread and changing the focus to how declare
works and how should it work, but I haven't replied what I think it's the
best practice for sharing patches...

so +1 for namespaces

But personally, I hate using them for my own stuff. I don't use [declare]
either, cause it still doesn't quite work for me, and we've been discussing
ways to improve/enhance it, as I pointed in my first reply here on this
thread.

for my own stuff, I just try to rely on as few libraries as I can, and I
just don't use objects that have the same name and do different things, so
I'm just happy to not bother with any namespace/declare nonsense, I just
add the libraries to my path and enjoy them

cheers




>
> The only things that needs to get fixed are some single binary libs. To
> put some random example some objects on iemlib already work with
> [iemlib/obj] and others don't.
>
> Makes me think that if zexy and iemlib (and other single binary) support
> [foo/obj] every thing will be under control.
>
> I'm not a Gem user so I don't know if it has potential name clashes
>
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 1/6/2018 10:41 AM, Christof Ressi wrote:
> >> (which actually might be tricky depending on platform/how their system
> is set up).
> > exactly, that's why it's better not to make any assumptions. just tell
> users: "needs zexy, cyclone ..." and it's their responsibility to add the
> necessary search paths/load libs if necessary.
> >
> > and again:
> >
> >>> imagine you want to use both [foo/obj] and [bar/obj] in the same
> >>> abstraction. how could you possibly force on or the other with
> >>> declare?
> >
> >> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr
> >> Von: "Derek Kwan" <derek.x.kwan at gmail.com>
> >> An: "Alexandre Torres Porres" <porres at gmail.com>
> >> Cc: "Christof Ressi" <christof.ressi at gmx.at>, Pd-List <
> pd-list at lists.iem.at>
> >> Betreff: Re: [PD] declare vs. namespaces - current best practice
> >>
> >>
> >>>> And to come back to my first remark here on this thread, if
> >>>> [declare] cannot always force a priority, shouldn't it?
> >>> I don't think so. [declare]'s job is to add paths to the search path
> >>> and load libraries. it has nothing to do with namespacing.
> >>>
> >>> imagine you want to use both [foo/obj] and [bar/obj] in the same
> >>> abstraction. how could you possibly force on or the other with
> >>> declare?
> >>>
> >> Well, I suppose one way of forcing the use of cyclone's gate without
> >> typing out the entire thing and dealing with this whole namespacing
> >> thing is to basically use the -noprefs flag when launching pd (and
> >> assuming the people you are distributing the patch to have Pd somewhere
> >> in their path which might be a big if, you can send along a shell script
> >> that launches pd with that flag for them) and using [declare] to control
> >> what gets loaded and what paths are added (which actually might be
> >> tricky depending on platform/how their system is set up). And of course
> >> not loading the prefs file affects more than just paths/loading...
> >>
> >> So maybe now that I type it out this isn't such a simple idea to
> >> implement haha, but maybe it could be helpful for some use cases...
> >>
> >> Derek
> >> --
> >> Derek Kwan
> >> www.derekxkwan.com
> >>
> > _______________________________________________
> > 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 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/20180107/7f1fc852/attachment-0001.html>