Thanks very much for the excellent explanation and examples! Between the Moose IRC channel and my own experimentation I cobbled together similar solutions, but the one you provided is much more clear.

In my real code, I use modifiers in child classes and roles (as you suggested), but when I was working on the example for this post I thought it might remove one more variable if I put everything in the same class. A weird design, I admit, but it demonstrated the issue.

Initially, I implemented your first method (extending the attribute in the child class). It seemed to work ok, but this part of the docs (Moose::Manual::Attributes) made me worry about fragility and future breakage:

Attribute Inheritance and Method Modifiers

When an inherited attribute is defined, that creates an entirely new set of accessors for the attribute (reader, writer, predicate, etc.). This is necessary because these may be what was changed when inheriting the attribute.

As a consequence, any method modifiers defined on the attribute's accessors in an ancestor class will effectively be ignored, because the new accessors live in the child class and do not see the modifiers from the parent class.

In particular, I didn't want to remember which changes in the parent/child class would be ineffectual in a subset of classes that extend the attribute in question.

As a result, I ended up using option 2. I like having "x_changed" as a named method, so I changed the trigger definition to be a coderef to an anonymous sub that calls "x_changed". Now I can safely modify that method without having to think too hard.

Thanks again. ++