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
i...@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 <i...@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
    <i...@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@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to