Hello.

May I first say that I really enjoy using Moose and appreciate the work that went into it. Thanks; you made the Perl object world a happier place (for me, anyway).

I've been building out an MVC webapp framework with Moose in recent weeks. A couple of concerns have come up:

* there appears to be a problem with making Moose-based modules (or perhaps, specifically, Class::MOP-based modules) refreshable (see Module::Refresh for what I'm talking about); you can force a particular module to be reloaded by Perl, but the attributes will break. I'm thinking this has to do with keeping a bunch of metadata about the Moose modules within the Class::MOP package(s). Have you, or do you know of anyone who has, ever looked into this sort of functionality? Making modules dynamically reloadable is a really marvelous thing when working in development environments (it's obviously something one would turn off in a production environment, of course).

* attributes in Moose/Class::MOP: they create methods within the package, and thus it would seem reasonable that said methods would be subject to modification via the various method modifiers; this works fine if one only uses the attribute accessor on an existing instance, but any method modifiers applied to the attribute will be invisible to the constructor, since the original attribute mutator is kept with a subref in the metadata object. I realize that defaults and triggers provide some degree of flexibility with attributes, but ultimately, maximum flexibility is achieved by using an around modifier on the accessor method; more philosophically, if an attribute is accessed/modified through accessor methods, shouldn't those accessor methods be modifiable just like any other method, to maximize the benefits of encapsulating the attribute behind a method?

Anyway, in the latter item, it seems to me that the keeping of the original attribute accessor method reference in the meta object, to be called directly by the constructor, makes for reduced flexibility and introduces some degree of inconsistency in the Moose interface. I presume it could be eliminated by some additional indirection/introspection within the constructor, which has a performance penalty (well worth it, in my opinion, but I'm just one person). Perhaps I'm entirely misinterpreting the situation, of course. :)

So, if you have any thoughts or comments on these topics, I'll be most happy to hear/read them. Thanks again for the great work.