in reply to (tye)Re: Closures and scope
in thread Closures and scope

We talk different. :-)

I am curious. I think of anonymous subs in terms of the variable that is holding them, not the function that created them. So if I have 10 variables in an array that each hold a code-ref, I would say that I have 10 anon subs, and not "3 copies of this one, 2 of that, and 5 of the other". I talk about passing anon subs to functions, etc, and this only makes sense to me if I think that way.

Besides which to me using anon subs is a way of hiding information. I use them because I explicitly don't want to and don't think this code should care about where stuff came from. So the constructor is at best irrelevant so long as the function does what it is supposed to!

So how about others? Are you with Tye in thinking about the internals of what gets compiled etc, or with me in thinking about anon functions in terms of the reference you can see in your variables?

  • Comment on RE (tilly): (tye)Re: Closures and scope

Replies are listed 'Best First'.
(tye)Re2: Closures and scope
by tye (Sage) on Oct 16, 2000 at 21:26 UTC

    The question was about internals (who holds the ref), so the answer was oriented that way as well.

    The reason that I so strongly made the distinction between the function and the reference to it, is because I wanted to stress that the reference (to the anonymous sub) going out of scope destroys the reference (to the lexical variable of the closure).

    And I also pass anonymous subs to functions. I pass them by reference. ;-)

    Note that Perl agrees with me: 

      CODE(0x1bbf074) is born.
[...]
  CODE(0x1bbf074) is born.

    [download]
    both closures are references to the same anonymous function.

    Now if there was a way to do undef( &anon ) then I could make the point even stronger. It'd also help if there was a way to have the subroutine code hold a reference to an Obit object so I could show it being destroyed when the (compiled code of the) anonymous function is destroyed. But I don't know how to do either of those, yet (but I have an idea of how I might be able to do one of those so I may post a follow-up about this in a bit).

    I will certainly be "sloppy" and talk about an "anonymous sub" when I more precisely mean a "ref to anon sub". There is no problem with that. If I come up with any cases where the distinction really matters (which appears to be quite difficult), then I'd quibble with such "sloppy" usage when specifically discussing these unusual cases.

    Note that having two references to the same hash and being sloppy and talking about having two hashes is likely to get you into a mess of trouble if you modify both of your hashes, for example. Since you can't modify code via the code ref, I vote for being "sloppy" most of the time.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]

      Note that Perl agrees with me: 

         CODE(0x1bbf074) is born.
 [...]
   CODE(0x1bbf074) is born.

      [download]
      both closures are references to the same anonymous function.

      Sorry, my mistake. The two different closures only managed to get the same address because their life spans did not cross (the first one was destroyed before the second one was created). If the first one had not been destroyed, then the second one would have gotten a different address.

      This is a good thing and can be important in certain situations so I didn't want to leave this mistake uncorrected.

      Thanks to Dominus for pointing this out to me.

              - tye (but my friends call me "Tye")
[reply]
[d/l]

In Section Seekers of Perl Wisdom