Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
"be consistent"
 
PerlMonks  

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

by AnomalousMonk (Monsignor)
on Aug 20, 2013 at 22:56 UTC ( #1050264=note: print w/ replies, xml ) Need Help??


in reply to Re: Modules: computing a constant, "on load" or in new()?
in thread Modules: computing a constant, "on load" or in new()?

... 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;


Comment on Re^2: Modules: computing a constant, "on load" or in new()?
Download Code
Re^3: Modules: computing a constant, "on load" or in new()?
by tobyink (Abbot) on Aug 21, 2013 at 07:00 UTC

    "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.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
      ... 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!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1050264]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (6)
As of 2014-04-20 18:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (486 votes), past polls