in reply to constants wont optimize

It's much much simpler than that:

use constant haveMod => $mod::VERSION; print haveMod ? "goodMod" : "badMod";

Replies are listed 'Best First'.
Re^2: constants wont optimize
by patcat88 (Deacon) on Jul 10, 2011 at 18:09 UTC
    I am trying to NOT use constant. use if eval { require mod; 1 }, qw' constant haveMod 1 '; can't get very complicated, cosmetically, For example, during running/compiling of the require of a use for a PM, probing the capabilities of the current OS/perl installation, including, calling XSUBs, setting the constant subs, then defining the subs that rely on those constant subs and having the perl compiler delete the subroutine branches for never to be used code path.

    I looked through the source of constant.pm, its doing something black magic, "mro::method_changed_in($classname)" and Internals::SvREADONLY to make its constant subs. Not the public Constant Functions way.

      Actually, as you've found out, your way is the complicated one.

      Simple:

      use constant haveMod => eval { require mod; };

      And for the non-trivial:

      my $haveMod; BEGIN { ...[ something complicated ]... $haveMod = ...; } use constant haveMod => $haveMod;
      or even
      BEGIN { ...[ something complicated ]... require constant; import constant haveMod => ...; }

      PS - require always returns true, so the "1" is redundant.

        I can't call "require". I am sniffing to see what PMs were loaded before the "use" that loads my PM. Its so my PM will integrate with other PMs loaded BEFORE my PM. Sort of like threads and threads::shared.