in reply to Re^8: UPDATED, mostly solved: separation of define + assignment different from combination?
in thread UPDATED, mostly solved: separation of define + assignment different from combination?

If you blanket replace P with printf STDERR and change Ehv to a direct access, you have you wish:
#!/usr/bin/perl use warnings; use strict; { package pkg; use warnings; use strict; our $cnt=0; sub new { my $p = shift; my $c = ref $p || $p; printf STDERR "pkg %s created\n", ++$cnt; $p = bless { cnt => $cnt, fnc => sub { my $p2 = ref $_[0] ? shift : __PACKAGE__; printf STDERR "fnc %d calling %s\n", $cnt, +$p2->FUNC; undef; } }, $c; } sub destroy { printf STDERR "pkg %s(%s) destroyed\n", $cnt, $_[0]->{ +cnt}; undef } sub DESTROY { goto &destroy } } package main; sub callfunc(;$$); #silence warn about proto not ready sub callfunc (;$$) { my $p = pkg->new; my ($callfunc, $recur) = @_; $callfunc||=0; $recur||=0; local * FUNC = sub () { printf STDERR "In FUNC, cnt=%s\n", $p->{cnt} +; undef }; FUNC() if $callfunc; callfunc($callfunc, $recur) if $recur && $recur--; } callfunc; callfunc 1; callfunc 0,1; callfunc 1,1; pkg::destroy
And you get the similar output with 2 subs in a text editor. inserting print STDERR for all of the Pe's and an extra '\n' for at the end of all strings. And a removal of the null pointer deref which isn't even used. But you still get an undef warning.
pkg 1 created pkg 1(1) destroyed pkg 2 created In FUNC, cnt=2 pkg 2(2) destroyed pkg 3 created pkg 4 created Subroutine main::FUNC redefined at /tmp/tst2.pl line 27. pkg 4(4) destroyed pkg 4(3) destroyed pkg 5 created In FUNC, cnt=5 pkg 6 created Subroutine main::FUNC redefined at /tmp/tst2.pl line 27. In FUNC, cnt=6 pkg 6(6) destroyed pkg 6(5) destroyed Use of uninitialized value in printf at /tmp/tst2.pl line 16. pkg 6() destroyed

Or you could spend 30 seconds and install the routines. They are simple routines and I explained my rationale for using them.

The differences in the final program are minor but I spend hours revising it in development where retyping pointless expansions is harmful and wasteful.

So if your help requires not being able to do 2 text subs or installing modules that do that for you automatically, then its obvious you are not someone I'd want creating toxic responses.

And before you claim you don't want to install modules that due unknown things -- they are simple modules, published on CPAN and backed by my name -- someone who is unafraid of signing it on their posts no matter how my post may make me look. It's called integrity and honesty.

  • Comment on Re^9: UPDATED, mostly solved: separation of define + assignment different from combination?
  • Select or Download Code

Replies are listed 'Best First'.
Re^10: UPDATED, mostly solved: separation of define + assignment different from combination?
by Anonymous Monk on Feb 13, 2014 at 13:46 UTC
      There is no difference in the sequence of when the objects are destroyed, so that doesn't yield much enlightenment.

      It looks pretty quirky for the given example, regardless of it possibly being valid if FUNC was called within the the defining local statement.

      I don't see the warning is necessary for *this* example.

      However, if, in a NESTED call, a "previous definition" of FUNC exists and theoretically could be called to do some function or return a value, from the "outer, non-nested iteration". In that case, the old FUNC is still around and should be usable in the assignment -- the old value of FUNC would be overwritten/redefined BEFORE the old/outer level FUNC had been completely saved off (which, I'm guessing, can't happen until the end of the 'local' statement.

      Given that the call to FUNC might not be easily determined while that statement is executing, (multiple local functions could be called, with their existence dependent on external state variables), I'd say the warning is probably necessary, as proving such would seem to be NP-hard.