sub foo {
    no warnings 'redefine';
    if ($cond1) {
        *foo = sub { ... };
    }
    elsif ($cond2) {
        *foo = sub { ... };
    }
    else {
        *foo = sub { ... };
    }
    goto &foo;
}
[download]

call_me_only_once() was meant to represent code that must be executed only on the first call to the function. I hadn't thought of the scenario you present, but I can see that the self-redefinition technique could be useful there too.

the lowliest monk

Seriously, what's wrong with a much easier approach like this?

our $FOO_HAS_BEEN_CALLED;

sub foo {
  if (not $FOO_HAS_BEEN_CALLED) {
      call_me_only_once();
      $FOO_HAS_BEEN_CALLED = 1;
  }
}
[download]

Yes. Next question.

Next question: why?

Seriously, what's wrong with a much easier approach like this?

Somebody could mess with the package global $FOO_HAS_BEEN_CALLED and blow things up, and call_me_only_once() gets called twice. Of course, call_me_once() disposing of itself properly after being called would make damn sure it isn't a second time :-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Why? Because it solves a simple problem in a complex and convoluted way.

Somebody could mess with the package global $FOO_HAS_BEEN_CALLED and blow things up

The "somebody could mess with it" argument has never been valid for Perl. Of course somebody could mess with it! Somebody could mess with absolutely everything in your program. If you want to prevent possible accidental changes, you could make it a lexical instead and let foo() be a closure around it. But no one mentioned security as the reason for this.

I still think it sounds like setup code that should be in some kind of BEGIN or INIT block.

Actually, there's no reason for it to be a package variable. I would have used a lexical. And bah! If someone shoots themselves in the foot by messing with internal state variables, it's their own foot. It's not like someone could accidently change the value of the variable.

Seriously, what's wrong with a much easier approach like this?

It could be much easier to read:

if (not $FOO_HAS_BEEN_CALLED) {

... if it were instead:

unless ($FOO_HAS_BEEN_CALLED) {

Otherwise, it seems reasonable.

Now that you mention it, I usually handle this kind of bail-out conditional with a simple test at the top:

return if $foo_has_been_called;
[download]

Then you don't have to indent the whole rest of the sub.

I object to that "easier" approach because it confuses the intent of the code; data which should be hidden from the rest of the program is revealed when you use global state this way.
Read more... (1232 Bytes)

Update: Re^3: Is modifying the symbol table to redefine subroutines evil? suggests using a lexical closure. That seems fine to me too, I just don't like the globals much.

Here it is without globals:

{
  my $foo_has_been_called;
  
  sub foo {
    if (not $foo_has_been_called) {
      call_me_only_once();
      $foo_has_been_called = 1;
    }
  }
}
[download]

There's nothing wrong with this approach. (I certainly hope there isn't because my own code is filled with instances of this pattern.) But it has always annoyed me to saddle a function with a test that is useful only once in its lifetime. It's a perverse sense of aesthetics, I admit it, but that is, at any rate, the motivation behind the gyrations... I was just wondering whether there were fundamental problems with the approach (other than its neurotic convolutedness).

the lowliest monk

There's nothing wrong with this approach. In fact, my own code is filled with instances of this pattern. But it has always annoyed me to saddle a function with a test that is useful only once in its lifetime. It's a perverse sense of aesthetics, I admit it, but that is, at any rate, the motivation behind the gyrations...

Yeah, I'm concerned too with "this kinda things": see for example Doing "it" only once which was brought up here by Limbic~Region, but inspired by a post I made in p6l. There, the situation was somewhat lower level in that it boiled down not to a matter of mangling the symtable, but even the optree itself. Unfortunately most people didn't get it in both places, that is p6l and here: just pointing out that there are many WTDI and asking "what's wrong with this one?" Both me, LR and those who actually understood are perfectly aware that there are many ways around it, but still find them all somewhat unsatisfactory for some reason.

To sum up what was going on in that thread, the mythological beast we were/are after is a statement modifier (or something like that) specifying that the statement itself must be executed once only, and then evaporate like it never existed, not being skipped upon a condition. There are fundamentally two categories of replies pointing out ways to do it without the mythological beast:

1. use a counter and skip over the statement when it's positive;
2. have a version of the loop with the statement that exits the loop when the statement is executed and then continue with a similar loop that does not contain the statement.

In the former approach you check a condition also after you're sure it won't be true anymore a priori, and you don't want it to be. In the latter you avoid this with some sort of code duplication that in certain circumstances may also require you some code factorization that would be otherwise unnecessary. Currently I would personally use the former when I'm not concerned about performance and the latter when I am, with a preference for the latter even in the first cases because I find it conceptually and aesthetically disturbing to perform unnecessary operations even if any overhead they introduce may be negligible. I long for a solution that gives me the best of both solutions on the base of conceptual and aesthetical considerations in that it should be syntactically simple like the first one and avoid unnecessary operations, like the second.

Somebody else, in that thread, pointed out that manipulations like those we were talking about were very common in early languages, but are now regarded as Evil™, and for good reasons that I can understand, the point still being that just like raw goto is also Evil™, Perl provides tamed forms of goto under the names of last, next and redo which are not and nevertheless make for very useful common Perl idioms. So, much in the same vein I do not long for generic means to achieve self-modifying code to be made excessively accessible, but for a tamed, specific, form of self-modifying code available as a teaspoonful of syntactic sugar simple enough to use from the typing-wise POV to make it elegant and appealing, and distinctive enough not to make it possible for one to use it inadvertently with the risk of being bitten in the neck by it.

I was just wondering whether there were fundamental problems with the approach (other than its neurotic convolutedness).

FWIW I find "its neurotic convolutedness" not to be terribly more relevant than the simple condition checking version.

I can't think of a more fundamental problem with any code than being more complex than it needs to be, except maybe giving the wrong answer.

my $foo; # Global, because this is the only visible (subroutine ref)

$foo=sub{
   print qq[First call - do first processing here \n];
   # First processing code goes here ...   
   
   # Now setup for subsequent calls .... 
  $foo=sub{
     print qq[subsequent calls\n]
     # Code for subsequent calls goes here
  }
};

$foo->() for 0..5; # OK - so the subroutine call looks slightly weird 
+to newbies.
[download]

If call_me_only_once() really should only be called once, then why not solve the problem there instead of in its caller? (You've already seen how to enforce single execution by scoping a variable outside the sub.)

Addressing the problem there would mean you wouldn't need to worry about bar() making a call to call_me_only_once(); presumably your program knows the answer to that question already.

--Belden

In principle it isn't though -- I know one team of programmers that likes to use a trick like this to swap in mock code during testing.

• It won't work if it's in a module that you're importing elsewhere (because you end up changing Module::foo, which is irrelevant to the ModuleUser::foo that was imported).

  You can change that with

    no strict 'refs';
    my $pkg = caller;
    *{ $pkg . "::foo" } = sub { ... }; # the final foo
  [download]

  but only if that's what you want ("call once per user" instead of "call once globally").
• There's no easy way to reset the trigger after it's fired. For your application, this is probably what you want, but you could imagine scenarios where it is not (eg mod_perl).

Personally, I like the idiom

sub foo {
  our $CALL_COUNT;
  call_me_only_once() unless $CALL_COUNT++;
  ...do stuff...
}
[download]

Aspect would be the Perl way to do this, but I don't know how to remove advice with it, so I'll demonstrate using Dojo. This is a Javascript library.

function foo () { ... };
function call_only_once () {
    dojo.event.disconnect( 'before', foo, call_only_once );
    // Do stuff here
};

dojo.event.connect( 'before', foo, call_only_once );

foo();
[download]

package OldeCrufte;
use deprecated qw(do_hack);  # calling OldeCrufte::do_hack() will carp
[download]

package OldeCrufte;
use deprecated;              # using the OldeCrufte module will carp
[download]