Christopher Brown wrote:
I have to agree with the above assessment. Tying 'strict' and 'immutability' doesn't make sense. They are orthogonal concepts. And, I am not a fan of Moose::Strict either. Yet another packages to remember, separate documentation. If you fork into use Moose and use Moose::Strict, someone will come along and create MX::UserProof, unaware of Moose::Strict. 'use Moose -strict' is sweet. It puts the right functionality in the right place.
I also think that object immutability and object constructors disallowing arguments that won't be used are orthogonal concepts.
Now, perhaps a bigger question that one might ask, is why wouldn't Moose use MooseX::StrictConstructor's semantics by default?
The main reason I can think of for the current behavior is that you may want objects to have constructor parameters that don't correspond to attributes, and you would be using BUILD to map them.
A solution for that conflict which could also serve additional uses is to have support for "virtual attributes", where you explicitly declare extra, redundant attributes with "has", say with a "virtual" trait or something, and then the incorporated MXSC semantics would then also allow constructor params of those names as well. How this solution serves additional uses is that for each virtual param an accessor method would be generated as with regular attributes, so that users could later retrieve or update that attribute on an object similarly to how they used it in the constructor, and these accessors don't have to be manually written by the class definers. Or they still sort of do, but mapping subs can be attached to the virtual attribute definition, same as subs are attached to say lazy attr defs, as is appropriate.
An alternate much simpler solution is to skip the virtual attrs thing and simply add a way for a class definer to explicitly declare what additional constructor args are allowed, so then the added strictness will only complain if an arg is neither in that list nor is declared normally as an attr.
So what are thoughts on this? Making vanilla Moose classes complain about extra constructor args by default, and then classes explicitly declare when they want it to do otherwise by saying what extra args are allowed?
-- Darren Duncan
