what if we introduce double dollar syntax to grab patch arguments?
Actually, I already thought about that. The problem is that "$" is only interpreted as a dollar or dollarsym if it is followed by a number. So currently "$$" is not a reserved token, meaning that "$$" is a valid symbol. We *could* reserve it, but we risk breaking some patches. Assuming that only very few patches will be affected by this change, we might decide that extending the functionality of message boxes is more important.
Christof
On 01.12.2021 21:22, Alexandre Torres Porres wrote:
I like the idea.
Em qua., 1 de dez. de 2021 às 17:14, José de Abreu abreubacelar@gmail.com escreveu:
I have an idea about $0 what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is) this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be coherent) this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think? Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres <porres@gmail.com> escreveu: Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else. Miller's response: Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette <msp@ucsd.edu> escreveu: I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...) It would be interestnig to allow message boxes to access canvas creation arguments somehow, but not that way. To which me and Christoph argued things like - /$0 is not a creation argument after all, i.e. it is not part of "ce_argv". Also, it really //has a different purpose. (...) $0 would be a special case either way./ - /It was also never documented as an 'argument'. (...) under a user perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting./ Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "\") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired. If this idea resonates well, I can try and open a PR for it and we can discuss the design details. see screenshot of the object cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list