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")