[PD-dev] [PD] Should message objects be able to pre-parse $0 into valid dollarzero?

[Jonathan Wilkes]

To address your initial query about why may naturally want $0 in msg boxes, in no particular order:
* the syntax for variables is the same in object and message boxes.  So when a user learns that $0 in an object box expands to a unique id, and $0 in msg expands to 0, their minds may naturally wander freely between the two separate contexts for the same combination of characters '$0'.  Some users reasonably wonder why msg expansion to "0", which is all but useless, might not be replaced by something useful like obj box $0.  The reasoning might not have the same impetus if, say, message box variables were something different like #1, \1, or `one.  In any of those cases, when the topic would arise users would probably ask about accessing dollar variables as a whole in the way you describe.
* $0 is almost always used for locality, whereas $1-$n are only sometimes used for locality.  Additionally, the user is _much_ more likely to do math with one of the values from $1-$n (add, multiply, etc.); they are likely never to do that with $0.  $0 and $0- prefix almost always mean "make this local", so users naturally want a way to say "make this local" inside a message box.  (They may also want to do math inside a message box, but that's way more complicated to do and do right than just fetching a single id, so users are less likely to vehemently push for that.)
* $0 itself has no natural or logical relationship to the sequence $1-$n because.  For example, $4 is the fourth atom in an array of atoms.  $3 is the atom immediately before $4, $5 is immediately after $4, and so forth.  But $0 is not the atom immediately preceding $1.  It is an inconsistency, users know this, and so they probably have a hard time seeing why adding an additional inconsistency to the msg box context is a problem.

* related to above-- for consistency $0 in an obj or msg ought to expand to the selector.  Since it already doesn't do this in obj boxes, users probably don't care that it doesn't (and won't) do this in a msg box

-Jonathan



On Saturday, September 13, 2014 4:15 PM, Roman Haefeli <reduzent at gmail.com> wrote:
 


On Fre, 2014-09-12 at 00:30 -0400, Ivica Ico Bukvic wrote:
> On 9/10/2014 2:21 PM, Miller Puckette wrote:
> >
> > A deeper question bothers me: what about $1, etc, too?  What if we're in an
> > abstraction and want to 'speak' to $0 in our calling patch?  THe usual way of
> > doing that is for the calling patch to instantiate the abstraction with $0
> > as an argument.  Then the abstraction itself can access it as, say, $1.  But
> > that makes me think we need a way for the message box to be able to access $1
> > as well as $0.
> >
> > It seems like this should either be something syntactic in messages themselves
> > (that could have deep repercussions as that is at the very heart of everything),
> > or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully)
> > there's a better way I haven't thought of.
> 
> This sounds like an interesting development but I am not sure if it 
> negates the immediate benefit of parsing $0 inside a message.

Chiming late here and I also might don't grasp the whole extent of the
current discussion, so please excuse me when I repeat things. 

While the topic arises every now and then, I fail to understand how
people seem to naturally want $0 in message boxes. It's not that I don't
see how it would come in handy. It certainly would have saved me a lot
of patching. However, dollar variables in object arguments are totally
different animals from dollar variables in message boxes. While in
objects they access arguments given to the parent, they are used in
message boxes to access a specific element of the incoming message. Why
should a $0 in a message box access the unique identifier of the parent,
but all other dollar variables an element of the incoming message?
Wanting $0 (as proposed!) in message boxes is actually wanting totally
different functionality depending on the variable name. Why are people
only complaining about a missing $0, but not about a missing $3? If I
want to access the third argument given to the parent in a message box,
I need to use the same kludge ([list append $3]-[$1( ) I have to use in
order to access $0. What is the difference? Ah yes, $3 already has a
meaning in message boxes, while $0 doesn't. Ok, $0 hasn't been assigned
a meaning yet, so let's give it a totally odd meaning. (excuse the
snarky tone).

In (my) ideal Pd world, message boxes would be able to access both, the
arguments given to the parent and the elements of the incoming message.
Since they are different things, I'd propose two different variable
prefixes, $ for arguments of the parent and # (or whatsoever) for
elements of the incoming list. Then we wouldn't only have $0 in message
boxes, but $3 from my example above would work as well. #0 would give
you the selector of the incoming message (that is also something that
currently cannot be accessed directly). 

Of course, this would _totally_ break backwards compatibility. Also I
don't know what technical implications such an implementation would come
with. Rationale trumps handiness, so personally I rather opt for
breaking backwards compatibility than for a kludge that still wouldn't
make sense in a hundred years when people would ask themselves: "What
does $0 mean in a message box? Ah yes, it is special ... "

Personally, I even prefer the status quo to the proposed use of $0. It
is cumbersome, admittedly, but I'd rather miss a feature than using a
feature that fully breaks the logic of the whole.

Roman


p.s. I may sound as I'd care a lot about the future of $0 in message
boxes. Actually, I do not so much. I certainly could live with the
proposed use of $0 in msg boxes. I'd consider it a kludge, nevertheless.

  


_______________________________________________
Pd-dev mailing list
Pd-dev at lists.iem.at
http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140913/43d7b64f/attachment.html>