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
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management
->https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
