[PD] pd_defaultbang to non-default list handler

Miller Puckette msp at ucsd.edu
Sun Jun 21 18:10:44 CEST 2020


As far as I know, there's no design necessity that says it has to be zero.
The selector in this case is unspecified.  One could invent one ("foo"
would be fine) or leave it at zero.

Perhaps objects should not depend on knowing a selector that might be
undefined.

cheers
Miller

On Sun, Jun 21, 2020 at 12:55:47AM +0200, Christof Ressi wrote:
> > I guess what I'm trying to ask is if there's a design constraint that
> > requires the selector to be null in said code. Or
> > better yet-- if the code were changed so that the selector is *never*
> > null would bad things happen?
> The selector is not *required* to selector to be NULL, but it *can* be NULL,
> with the only merit that it saves you a few characters.
> 
> > if the code were changed so that the selector is *never* null would bad
> > things happen?
> In the above mentioned discussion, IOhannes has offered two patches: 1)
> don't use NULL selectors internally, 2) gracefully handle NULL selectors
> (e.g. coming from externals)
> 
> Those patches obviously haven't been merged, but I think they should be
> reconsidered.
> 
> Christof
> 
> 
> On 21.06.2020 00:47, Jonathan Wilkes wrote:
> > > On Saturday, June 20, 2020, 6:34:02 PM EDT, Christof Ressi
> > <info at christofressi.com> wrote:
> > 
> > > In pd_defaultbang, what is the reasoning for calling the list method
> > > with a null selector while calling the
> > > anything method with an "&s_bang" selector?
> > > contrary to the list method, the selector for the anything method
> > *does* carry significant meaning. At the very least, it's necessary for
> > the default anything method (which prints an error message).
> > 
> > I guess what I'm trying to ask is if there's a design constraint that
> > requires the selector to be null in said code. Or
> > better yet-- if the code were changed so that the selector is *never*
> > null would bad things happen?
> > 
> > Thanks,
> > Jonathan
> > 
> > Christof
> > 
> > On 21.06.2020 00:29, Christof Ressi wrote:
> > 
> > Ah, sorry, I misread you're last reply. I thought you were repeating
> > your first question :-)
> > 
> > On 21.06.2020 00:24, Christof Ressi wrote:
> > 
> > Did you read the discussion I've linked too? To quote Miller:
> > 
> > > I'm not sure this is a real problem - _anything and _list methods
> > > simply aren't guaranteed
> > > anything about the "s" argument - it shouldn't ever be dereferenced.
> > 
> > I think this is the answer to your question. Since the selector of a
> > list message is actually redundant, you're free to pass NULL.
> > 
> > Christof
> > 
> > On 21.06.2020 00:16, Jonathan Wilkes wrote:
> > > On Saturday, June 20, 2020, 4:02:44 PM EDT, Christof Ressi
> > <info at christofressi.com> <mailto:info at christofressi.com> wrote:
> > 
> > 
> > > Hi, the selector for a list method certainly shouldn't be "bang",
> > rather it should be "list".
> > 
> > Let's back up.
> > 
> > Miller,
> > 
> > In pd_defaultbang, what is the reasoning for calling the list method
> > with a null selector while calling the
> > anything method with an "&s_bang" selector?
> > 
> > Thanks,
> > Jonathan
> > 
> > > There has been a discussion about this in the past and I have agree
> > with IOhannes that Pd shouldn't send NULL selectors: https://urldefense.com/v3/__https://sourceforge.net/p/pure-data/patches/555/__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBR6LaLUw$
> > .
> > 
> > > Christof
> > 
> > On 20.06.2020 21:19, Jonathan Wilkes via Pd-list wrote:
> > Hi Miller,
> > 
> > In pd_defaultbang of m_class.c, why does the list method get called with
> > "0" for a selector instead of "&s_bang" for the c_listmethod invocation?
> > 
> > Best,
> > Jonathan
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at  <mailto:Pd-list at lists.iem.at>  mailing list
> > UNSUBSCRIBE and account-management ->https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$
> > _______________________________________________
> > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at  <mailto:Pd-list at lists.iem.at>  mailing list
> > UNSUBSCRIBE and account-management ->https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at  <mailto:Pd-list at lists.iem.at>  mailing list
> > UNSUBSCRIBE and account-management ->https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$
> > _______________________________________________
> > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$ 






More information about the Pd-list mailing list