not confusing, thanks
2014-04-03 19:54 GMT-03:00 Roman Haefeli <reduz...@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 <reduz...@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 >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list