Creating accessors on the fly, or not...

~~David~~ has asked for the wisdom of the Perl Monks concerning the following question:

I am writing a module which reads in flat text files that are made of fields which contain a tag followed by a value (ex: Time 16:43:25; ). I know ahead of time what tags are allowed, but there are quite a few of them.
I can think of two options to write this:
1.) Write an individual accessor for each tag
2.) Do this (which is what I have done but don't know if it is alright to do>:

after 'file' => sub { 
    my $self = shift;
    open my $FILE, "<", $self->{file};

    HEADER:
    while ( <$FILE> ){
               
        my ( $tag, $value ) = $_ =~ /\s*(\w+)\s(.+)/;
        
        my $accessor = lc $tag;
        
        #create an accessor for each header value
        has $accessor => ( is =>'ro' );
        $self->{$accessor} = $value;
    }
    
    close $FILE;
};
[download]

Maybe I have the wrong idea completely, but I was just wondering if I should choose one way or the other. The Moose tutorial says you should try to __PACKAGE__->meta->make_immutable; which my current method doesn't allow me to do...

Comment on Creating accessors on the fly, or not... Select or Download Code

Replies are listed 'Best First'.
Re: Creating accessors on the fly, or not... by stvn (Monsignor) on Jun 13, 2009 at 02:19 UTC
he Moose tutorial says you should try to __PACKAGE__->meta->make_immutable; which my current method doesn't allow me to do... Yes, because make_immutable makes your class readonly so you can't add methods to it (at least not via the MOP). You can however make a class mutable again with $class->meta->make_mutable and then make it immutable again after that with $class->meta->make_immutable. Of course there is a performance penalty with this, but it's not nearly as bad as you might think. And lastly, I would suggest replacing `has $accessor => ( is => 'ro' );` [download] with the more MOPish `$self->meta->add_attribute($accessor, (is => 'ro'));` [download] -stvn	[reply] [d/l] [select]
Re^2: Creating accessors on the fly, or not... by dsheroh (Monsignor) on Jun 13, 2009 at 12:16 UTC
Can you point me to a good explanation of why `make_immutable` is recommended? Going through the first 50 google results for "perl moose make_immutable", I came across a few statements that "make_immutable is a Moose best practice", but none of them stated the reason for it. Is this solely because it makes object creation faster (as shown by Pichi's Moose benchmarks) or are there other reasons aside from performance?	[reply] [d/l]
Re^3: Creating accessors on the fly, or not... by stvn (Monsignor) on Jun 13, 2009 at 18:07 UTC
Can you point me to a good explanation of why make_immutable is recommended? So in an effort to contribute to the Iron Man blogging challenge I have posted a response here. I will copy the "short answer" part of my post here, but for a more detailed and in-depth explanation check out the blog post. So the short answer is that making your class immutable is good because it memoizes several metaclass methods and installs an optimized constructor and destructor for your class and therefore helps reduce a fair amount of the cost (during runtime) of all the abstraction that the MOP provides. -stvn	[reply]
Re^4: Creating accessors on the fly, or not... by dsheroh (Monsignor) on Jun 14, 2009 at 10:30 UTC
Re^2: Creating accessors on the fly, or not... by lodin (Hermit) on Jun 14, 2009 at 07:14 UTC
And lastly, I would suggest replacing `has $accessor => ( is => 'ro' );` [download] with the more MOPish `$self->meta->add_attribute($accessor, (is => 'ro'));` [download] I'm curious—is there any actual difference (direct or indirect), or is it a matter of principle? lodin	[reply] [d/l] [select]
Re^3: Creating accessors on the fly, or not... by stvn (Monsignor) on Jun 15, 2009 at 00:39 UTC
No, there really is very little difference, they are basically equivalent. I guess is it a matter of principle, the declarative "sugar" is meant to be used during class definition time and the MOP is meant to be used at all other times. But, that all said, it might make more difference when we work out how to "compile" Moose classes (though I don't know this for sure) because part of that plan would involve caching the generated metaclass and then possibly turning the sugar keywords into noops (at least that was a path we explored in the early MooseX::Compile prototypes). So I guess if you really want to future proof things, it is best to use the MOP in this context. Hopefully by the end of YAPC::NA next week we will know more, it is one of the key topics on the Moose hackathon agenda. -stvn	[reply]