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

Personally I'd do something like this:

package Foo::Bar;

use Regexp::Assemble;

our $VERSION = '0.01';
my $regex;

sub new {
    my $class = shift;
    my $self = bless({@_}, $class);

    return $self;
}

sub function {
    my $self;

...

    $regex ||= Regexp::Assemble->new->add( 'some-stuff' )->re;
    $var =~ $regex;
}
[download]

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

Type::Tiny does this sort of thing all over the place, and it's fast. :-)

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

Comment on Re: Modules: computing a constant, "on load" or in new()? Download Code

Replies are listed 'Best First'.
Re^2: Modules: computing a constant, "on load" or in new()? by AnomalousMonk (Archbishop) on Aug 20, 2013 at 22:56 UTC
... 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;` [download]	[reply] [d/l]
Re^3: Modules: computing a constant, "on load" or in new()? by tobyink (Canon) 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`	[reply] [d/l]
Re^4: Modules: computing a constant, "on load" or in new()? by AnomalousMonk (Archbishop) on Sep 08, 2013 at 04:17 UTC
... 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!	[reply]