Re: [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
<i...@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
<i...@christofressi.com> <mailto:i...@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@lists.iem.at  <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at  <mailto:Pd-list@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@lists.iem.at  <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list