[PD] pd_defaultbang to non-default list handler

[Christof Ressi]

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$