[PD] pd_defaultbang to non-default list handler

Sun Jun 21 19:05:15 CEST 2020

I think 'anything' messages should always have a non-null selector.
The only place I know of where a NULL sepector should be OK is the 'list'
message.

cheers
Miller

On Sun, Jun 21, 2020 at 06:28:18PM +0200, Christof Ressi wrote:
> Hi Miller,
> 
> > Perhaps objects should not depend on knowing a selector that might be
> > undefined.
> The problem is that it is not really clear which selectors are allowed to be
> NULL, since it isn't explicitly stated anywhere :-)
> 
> Just for clarification: Do think that NULL is also a valid selector for
> "anything" messages? Pd doesn't perform any NULL checks before dereferencing
> the selector of such messages, e.g. in "print_anything" or
> "pd_defaultanything", so to me that suggests that NULL is only a valid
> selector for "list" messages.
> 
> Christof
> 
> On 21.06.2020 18:10, Miller Puckette wrote:
> > 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$
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!WbLawqtPagIG5h5Ff-FN0CraICMrdFKLFiZewRO8J-yR6dnwn1ZIptwzLxVL$