Re: Creating accessors on the fly, or not...

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

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

Replies are listed 'Best First'.
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
Thanks for the very thorough answer! It really clarifies why, in Pichi's benchmarks, the immutable version creates objects about 10x faster than the mutable one. (And I'm always happy to provide someone with an excuse for an Iron Man post, seeing as I always seem to be looking for them myself.)	[reply]
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]