not confusing, thanks
2014-04-03 19:54 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote:
Wow, you keep beating that horse after its dead for quite a while by now
I don't think this debate is going lead anywhere
please, cope with my lack of knowledge in computer science/languages jargons.
I'm sorry. I sure will (though I don't feel I have in any way less of a lack of knowledge). Actually, I don't have any computer science background myself.
All I'm doing is asking to learn more about it and get what you guys mean. I'm not debating, since I'm even stating I couldn't do it when I say I probably won't be able to grasp all the details and will just take the word for it...
So relax, you keep misjudging before reading more carefully. I'm not looking for a debate, and I'm also saying I'm cool with Pd's workaround myself, so there's no personal frustration. As I said, I'm not even thinking about me as my concerns come from luring people into using Pd, while I'm already sold for it.
Anyway, having said that, I'd appreciate if anyone could help me understand Pd's structure and developing issues.
I think I can't answer that.
For instance, I don't think I understand what "inconsistencies" mean in this context.
I try to explain some more. The confusion probably comes from the fact, that a similar looking syntax is used for two relatively different things in Pd. A $1 in an object box is substituted by the first argument I give to the parent abstraction. If I create [myabs 0.3] and myabs contains an [f $1], the value of $1 actually is '0.3'. If I have a message box [bla $1( in the same abstraction [myabs], we actually don't know yet what the value of this $1 is. Only when we send message to [bla $1( we know what the value of $1.
[1.7( | [bla $1(
When I click the [1.7( message box, we know that the $1 in [bla $1( is going to be substituted by 1.7. So far, so good.
We now have encountered two different $1s in the same abstraction. Once it got substituted by 0.3 and once by 1.7, although both are written $1. Confusing, isn't it?
I know that is nothing new to you at all as you most likely have used dollar variables in both ways already. What I am trying to say is that a $1 in a message box [bla $1( is a different animal from a $1 in an object box [f $1]. Pd could have been designed to make this distinction more explicit. It could have used # variables for message boxes and $ variables for object boxes. Then we would be able to do both with message boxes, namely expanding to a parent's argument AND expanding to an element of the incoming message, depending on whether we use the # or the $ syntax.
[1.7( | [bla #1(
In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we click the [1.7( message box (as does $1 in the real Pd). Clicking on [1.7( would output 'bla 1.7'.
[1.7( | [bla $1(
In our hypothetical Pd, $1 would hold the value of the first argument given to the parent abstraction [myabs 0.3], in our example '0.3'. Clicking the [1.7( message box would output a message 'bla 0.3'. However, there is no such thing in the real Pd (yet).
In the real Pd, the $1 in the message box works totally differently from the $1 in the object box. The canvas local-ID unique to each instance of a .pd file (abstraction or patch) can be considered as an argument to that abstraction or patch. Thus it can easily be accessed by $0 in object boxes.
When you propose that $0s in message boxes are substituted by the canvas-local ID, then you want the function of the dollar variables to be different depending on what number follows the dollar sign. You want $0 to access an argument given to the parent, but $1 to be substituted by the first element of the incoming message. That is where the inconsistency happens: Why should the function be different based on the value I put after the dollar sign?
In our hypothetical Pd, this would be a non-issue. You wouldn't expect a #0 in message box to get substituted by the canvas-local ID. You would use $0 for that. In the real Pd, we unfortunately don't have direct access to the arguments of the parent from message boxes. When you ask "Why can't a $0 in a message box be substituted by the canvas-local ID", then you also should ask "Why isn't a $1 in message box substituted by the first argument given to the parent?" The answer is that this is the way Pd is designed.
I'd prefer our hypothetical Pd, if it would exist. However, switching from today's Pd to our hypothetical Pd would surely break compatibility, which makes its introduction a bit less likely. Finally, I don't see any other concise solution than our hypothetical Pd for the $0-in-message-boxes problem.
I hope I didn't cause even more confusion.
Roman
2014-04-03 17:03 GMT-03:00 Roman Haefeli reduzent@gmail.com: On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote: > thanks for explaining it all > > > > imagine trying to design something like that > > which is also backwards compatible with the > > crude namespacing tools that already exist in Pd. > > It's not possible > > > ok, here's where I'm a bit confuse. You're not saying it'd be > impossible to make messages inherit the $0 value, are you?
Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages. While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list