Re^2: Modules: computing a constant, "on load" or in new()?

[AnomalousMonk]

... delay the compilation to the last possible moment, and then keep the result for future invocations to use.

If one were dealing with a lexical variable as in your example, and if the class was defined entirely within a file, and if the file/module was loaded only via a use statement, what would be the advantage of postponing initialization? If all the above conditions held, there could be no "order of evaluation" effects. Why would the following not be better because run-time (Update: well, 'run-time' is not quite the right term here, but you know what I mean) evaluation is entirely avoided? (In fact, it might even be better than the approach I posted here because you would be dealing with a 'pure' lexical variable without the interpolation problems associated with constant entities. However, methods or functions within the class could still change it, so it could not be considered a 'pure' constant.)

package Foo::Bar;
...
my $regex = qr{ hello }xms;
...
sub new { ... }
...
sub method {
  my $self = shift;
  ...
  if ($self->{bar} =~ m{ \b $regex \b }xms) { ... }
  ...
  }
...
1;

[tobyink]

"If one were dealing with a lexical variable as in your example, and if the class was defined entirely within a file, and if the file/module was loaded only via a use statement, what would be the advantage of postponing initialization?"

There might be a few dozen such items, each of which is reasonably costly to compile, and in a particular invocation of the program, only one or two (or perhaps even none in the case where the program has been invoked with the --help parameter) actually need to be used.

[AnomalousMonk]

... a few dozen such items, each of which is reasonably costly to compile, ... [perhaps] only one or two ... actually need to be used.

Sorry to be so long in answering.

I understand your point about postponing expensive initializations, and I would be inclined to agree in very extreme cases (e.g., an initialization that involved uploading your entire hard-drive to TheCloud™ via a dial-up ISP link). However, my general inclination, even in cases of fairly expensive initializations or object constructions, is to fail as early as possible, if fail one must. Operations that are more expensive tend to be operations that are more prone to failure. If such an operation is postponed until you are in the middle of another, perhaps critical, operation, error handling and recovery can become much more complex. In general, I think it's best to find out your cans of kerosene are empty before you start out for the South Pole, not on the way back!