[PD] pd_defaultbang to non-default list handler

Sun Jun 21 18:59:04 CEST 2020

I think Pd handles this somewhat inconsequentially. Sometimes, it calls 
list methods with 0, sometimes with &s_list. External developers might 
think that their code works, but it would crash in other places (as 
happened with zexy's [relay]).

Maybe Pd could always internally call list methods with a NULL selector, 
so that it's clear that the selector is not to be used?

Christof

On 21.06.2020 18:28, 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://lists.puredata.info/listinfo/pd-list