Karen Etheridge wrote:
On Wed, Mar 03, 2010 at 12:52:56PM -0800, Darren Duncan wrote:
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.
I've wondered this myself. I don't want arbitrary fields springing into
existence in my object, even if they don't have the overhead of a
full-blown attribute. For that matter, I don't want a field on my object
without the attribute interface -- one of the reasons for attribute
accessors is so I never have to type $obj->{fieldname} again. So I don't
want data being put there in a plain old hash key; if I wanted it, I'd have
made an attribute for it, wouldn't I?
FWIW, I also really like the approach used in MooseX::SlurpyConstructor,
where all "extra" constructor arguments are stored together in a slurpy
attribute. I see a strict constructor as a simple extension of a slurpy
one, using the base case of zero slurpy fields being allowed.
tl;dr version: I'm all in favour of strict construction being the default,
and slurpiness being the next best thing for the remaining cases.
AFAIK, all the StrictConstructor does is warn you about constructor arguments
that are going to be ignored because no attribute is defined to capture them,
and also that this may be a more serious problem than a no-op because some other
similarly spelled attribute isn't being set at all.
I'm not aware that the problem you state, about arbitrary fields springing into
existence, actually happens. I certainly wouldn't expect it to happen.
-- Darren Duncan
