[PD] '$0' in messages again, another proposal? (Was: Pd 0.52 test 2 is out)

[Christof Ressi]

Hi Ico,

I already made my own PR a few years ago: 
https://github.com/pure-data/pure-data/pull/347

> Another consideration is that there is a bit of a CPU overhead in 
> dynamically allowing $0 to be expanded.
AFAICT, my implementation actually *saves* a little bit of CPU because I 
cache the $0 value once in the message box constructor and then pass it 
explicitly to the new binbuf_doeval() function.

the current message box implementation calls binbuf_eval() which would 
query the $0 every single time (and we don't even use it :-)

Christof

On 02.12.2021 17:10, Ico Bukvic wrote:
> If you would like to test if $0 works inside messages as originally 
> suggested by Alexandre, you can try pd-l2ork. This is what it has been 
> using for quite some time now, although the use cases of $0 inside a 
> message remain relatively sparse. Another consideration is that there 
> is a bit of a CPU overhead in dynamically allowing $0 to be expanded.
>
> Best,
>
> Ico
> -- 
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Director, Human-Centered Design iPhD
> Institute for Creativity, Arts, and Technology
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
>
> ci.icat.vt.edu  <http://ci.icat.vt.edu>
> l2ork.icat.vt.edu  <http://l2ork.icat.vt.edu>
> ico.bukvic.net   <http://ico.bukvic.net>
>
>
> On Thu, Dec 2, 2021 at 8:34 AM Christof Ressi <info at christofressi.com> 
> wrote:
>
>     I think you're extrapolating from your particular use case.
>
>     I would say most people use $0 for private variables/resources. In
>     this case the very point is that those are not accessible from
>     outside. If I do want to make things accessible from the outside,
>     I wouldn't use $0 in the first place...
>
>     On 02.12.2021 14:25, Antoine Rousseau wrote:
>>
>>         Without the "$$" syntax, I wouldn't see the problem...
>>
>>
>>     encouraging the use of $0 in messages, without allowing to easily
>>     substitute with [another way to identify the abstraction] $1?..
>>
>>
>>
>>     Le jeu. 2 déc. 2021 à 13:18, Christof Ressi
>>     <info at christofressi.com> a écrit :
>>
>>>         So I think it's better to keep the $0/$n symmetry.
>>>
>>>             I think having a "message" object is a better idea [than
>>>             $$'s one]
>>>
>>>
>>>         What I like with the $$ idea, is that it would provide a
>>>         simple way to merge creation arguments with variable
>>>         arguments, i.e compose a message with both the abstraction
>>>         arguments and the incoming message elements.
>>
>>         I have to say I quite like the "$$" idea as well, assuming
>>         that we can take the risk of breaking a few patches (if any).
>>
>>         I don't think it's a good idea to add a new object just for
>>         this functionality. For me this would create unnecessary
>>         complexity (you have to learn yet another object).
>>
>>>         I'm not sure either. To me, both $0 and $1 etc. can be used
>>>         to identify an instance of an abstraction.
>>>         IMO $0 is the quick way, but has the limitation to make it
>>>         (nearly) impossible to access members from the outside.
>>>         That's why it often happened to me to rename an instance
>>>         [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs]
>>>         with $1, so I can easily access [myAbs]'s members from the
>>>         parent - from anywhere in fact (Actually, nowadays I tend to
>>>         use as few $0 as possible).
>>>         If we could use $0 in messages, then the last operation
>>>         would be more complicated (cause you couldn't simply
>>>         substitute $0 with e.g $1).
>>
>>         I agree that if we get the "$$" syntax, then it makes more
>>         sense to use "$$0" for the $0 argument! Without the "$$"
>>         syntax, I wouldn't see the problem...
>>
>>         One downside of using "$$0" is that it wouldn't be compatible
>>         with Pd-L2Ork / PurrData.If they have already diverged
>>         significantly, we probably don't have to care, but otherwise...
>>
>>         _______________________________________________
>>         Pd-list at lists.iem.at mailing list
>>         UNSUBSCRIBE and account-management ->
>>         https://lists.puredata.info/listinfo/pd-list
>>
>     _______________________________________________
>     Pd-list at lists.iem.at mailing list
>     UNSUBSCRIBE and account-management ->
>     https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211202/a33937a2/attachment-0001.htm>