From patching I know that it would be far more convenient to be able to reference the patch-local $0 variable in messages. 
Perhaps in that case there should also be a [selector] object that reports the selector of a message? getting it using [route] seems
unnecessarily complicated..

On the other hand, having $0 represent the selector would be the most consistent solution, because you can not get other patch-local variables
or arguments in message boxes, and yet you can use $1 $2 etc. to refer to the elements of an incoming message. So the behavior of dollar signs
in object boxes and message boxes is already separate and have very different uses. It almost would seem more confusing to be the same
for just 1 of the dollar sign numbers, yet different for all the others.

-Seb

-----Original Message-----
From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
To: pd-list <pd-list@lists.iem.at>; Roman Haefeli <reduzent@gmail.com>
Sent: Wed, Apr 4, 2018 1:00 am
Subject: Re: [PD] suggestion: $0 in messages

> Why is nobody complaining about not being able to use the third
> creation argument directly withing a message? What's the fuzz about the
> $0?

$0 isn't part of the argument vector. It's a unique id automatically
generated for a patch/abstraction which the user happens to access
through a dollarsign variable.

That locality hack doesn't require that the unique id be fetched by
an unused dollarsign arg. For example, you could reserve the keyword
"let" such that a message box with "let token2" would get converted
behind the scenes to "1003-token2".

When users for a decade have said they wanted $0 in msg boxes,
they mean that they want to use Pd's notion of send-symbol locality
inside message boxes. They want that instead of manually querying 
the value of a reserved dollarsign variable and sending that value
to the relevant message box in order to get "let" behavior.

Also, since "$0" is already being used for this purpose it doesn't
make much sense to try to also get "$0" to refer to the selector. 
You'd end up with inconsistent meaning where it fetches the 
selector in msg boxes but not in object boxes. Plus you can 
already get the selector of an incoming message with [list] 
whereas you cannot get an abstraction's selector (which would 
be handy for error reporting). So adding that inconsistency 
would only duplicate existing functionality without adding 
new functionality.

-Jonathan

> Roman
_______________________________________________
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