in reply to Which phase am I in?

I consider these phases arbitrary, and code which relies on them is fragile.

Suppose that you have a module that I require from the body of my code. Then your BEGIN happens at the main run time of the program, and you never see CHECK or INIT. If you depended on initializations happening in CHECK or INIT, then they didn't. (Guess why I avoid attributes?) In fact if the require is triggered by a function call in an END block, then your BEGIN may be nested in an END. Going the other way if there is a compilation error, then even normal END blocks might be triggered while you are in compile phase.

If you're doing mod_perl development with Apache::Reload, then this matters a lot because you will be reloading stuff at runtime. Being able to work with this module can speed up your development cycle a lot.

So is BEGIN earlier or later than CHECK or INIT or END? It varies. Which ones are guaranteed to happen in your program? Assuming no errors, only BEGIN and END.

Therefore I consider CHECK and INIT, or anything that depends on stuff happening during CHECK and INIT, to be fragile and to be avoided. (Then again I'm an old curmudgeon...)

Replies are listed 'Best First'.
Re^2: Which phase am I in?
by dragonchild (Archbishop) on Nov 20, 2004 at 04:15 UTC
    So, Oh Wise Curmudgeon, how would you write code that needs to do things after all compilation is done, but before execution starts?

    Real-life situation - I'm working on a class lazyloader (RFC: Object::Proxy (or somesuch) - ignore the Proxy part). The implementation I have chosen is to insert my own constructor in place of the constructor provided by the original author and rename the original one. However, my lazyloader will probably be used at the beginning and the constructor defined a bit later. I cannot rename what isn't there. In addition, I have to do my magic before anything calls the original constructor. What should i do?

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
      I wouldn't try to write that code.

      Or if I did, I'd do as some of the modules that you rejected did and not try to retrofit semantics onto the existing module. Instead I'd provide the lazy version of the constructor under a different name.

      And an extension of what I said above is that I won't choose to use modules - including the one that you're writing - that depend on working that way. Because how they are trying to be clever conflicts with how I'd prefer to be clever, so they will be fragile for me.

[reply]
        Fair enough. What kind of disclaimers should be put into the POD? I'm looking for ways to warn people that this may not work if they get clever in certain ways cause we're being clever in certain ways.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

      That's the problem with any code that fmucks with the Symbol table!

      Of course, if you call it "mucking with the symbol table", then you can look down your nose at it, with assurdness that "you shoudln't be doing that".

      If you called "Introspection", or "dynamic programming", then (at least in some languages), you could laud it it as a "useful, valueable, even desirable feature of the language".

      Examine what is said, not who speaks.
      "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
      "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
      Class::Autouse won't cut it for you as a class lazy-loader?
[reply]
        That lazyloads the class itself, not instances of the class. Our module creates lazy instances of each object on-the-fly. Maybe it should be called Object::LazyLoader, but it is really intended to work on the class level, so we're looking at Class::LazyLoader.

        (Note: I answered that question in the thread, towards the bottom.)

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

In Section Seekers of Perl Wisdom