Hello,
I tried to post this to the Pd mailing list but for some reason it didn't go through. I'll repost it here.
Hi list,
[namecanvas foo]
[traverse foo, bang(
|
[pointer]
|
[$1, $1 two(
|
[print]
Currently, evaluating the binbuf "$1, $1 two" will silently fail to output anything. That's clearly wrong.
Now, consider this:
[namecanvas foo]
[traverse foo, bang(
|
[pointer]
|
[print]
Here, the outgoing pointer calls the pointer method of the [print] object. There are many other objects which have a defined pointer method.
So if we want the behavior to be the least surprising as well as the least likely to cause bugs, the "$1" above should be equivalent to just sending the output from [pointer].
That would mean that a message box that expands to a single gpointer should trigger the pointer method for the target object (i.e., the object the message box connects to). That will ensure it triggers the pointer methods for classes which define one, as well as triggering the default Pd pointer handling for classes which don't.
This change seems pretty needed. I see all kinds of patches in the wild where users are doing weird things in object chains to handle pointers. It appears these users are hitting this bug and just pentesting the message until the gpointer finally flows out of the message box. (Which can happen with "list $1", or even "wtf $1" with a list split and trim following it.)
The remaining question is what to do about "$1 two."
It would be nice to convert it to a list in that case. That would match the behavior of Pd messages with leading numbers, as well as keeping with the common knowledge that Pd messages begin with a symbolic selector (or at least an implied one). However, gpointers break that pattern because there was no "pointer" selector reserved, implied or otherwise, in Pd. Thus, arbitrary messages beginning with the selector "pointer" can be followed by arbitrary arguments which in no way imply a gpointer payload. For example, "pointer 50 25" can be sent to [route pointer] which will happily output "50 25".
That means that going forward there's no way to reserve "pointer" in the way that, say, "float" is reserved. For example, if you try to type "float boat" in a message box Pd will tell you that "boat" is a bad argument for the "float" message. It's not allowed. And if we made a requirement that only a gpointer arg may follow the "pointer" selector it would probably break some existing patches in subtle ways.
So there are only two sensible behaviors left:
- Error out in message boxes for a multi-arg message that has a gpointer selector
- Call pd_anything to handle the "$1 two" example above.
I guess the determining factor would be whether multi-arg messages with interspersed gpointers are currently being used at all. Unfortunately, they probably are since [struct] will output messages like "click (gpointer) 50". Simply using a [route click] will then output a multi-arg message that has a gpointer selector.
That means Pd is already implicitly supports sending around "(gpointer) arg1 arg2 etc." messages to arbitrary objects. And I assume that any future crashers from that would be fixed. So it's probably no worse to allow message boxes to forward on such messages using pd_anything.
Thoughts? If not I'm probably going to start building some tests for this and
implement it in Purr Data after the next release.
-Jonathan
