Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Should MooseX::StrictConstructor be part of Moose itself?

by boftx (Deacon)
on Nov 14, 2013 at 03:54 UTC ( #1062524=perlmeditation: print w/replies, xml ) Need Help??

I have made it a practice to always use MooseX::StrictConstructor in my code, mainly because I got bit by a typo in a constructor attribute once. After that happened, I suggested to my team that we adopt this as a "best practice" policy but was voted down. One of the reasons being that if I wanted something like that I should be using Java, not Perl.

Granted, that is an argument I have used in the past, mainly to object to inside-out objects. (And I still object to them, but at least they seem to be a moot point today.)

However, I don't think that argument applies in this case. Nobody would argue that use strict; takes away from the spirit of Perl. And if one bears in mind that use Moose; automatically sets strictures then it seems that having strict constructor attributes would be a natural extension of that.

I can't think of any case where the ability to send a parameter in the constructor that could be handled only by say BUILDARGS or BUILD would outweigh the protection against a typo in a hash key. If anything, it seems to me that not having attributes declared in a has statement goes against the very purpose of using Moose in the first place.

My question is this: Does the use of MooseX::StrictConstructor move Perl in a direction that is more in line with strongly typed languages, or is it such common sense that the Moose Cabal should consider making it an automatic feature of Moose itself?

Update: minor grammar corrections, added CPAN links as needed.

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Replies are listed 'Best First'.
Re: Should MooseX::StrictConstructor be part of Moose itself?
by tobyink (Abbot) on Nov 14, 2013 at 07:34 UTC

    I agree with the sentiment, however it is currently possible for BUILD methods to do useful things with parameters that were passed to the constructor but don't correspond to any attribute names. MooseX::SlurpyConstructor is an example thereof. So if any such feature were added to Moose, it would have serious backwards compatibility problems, meaning that realistically it would have to be opt-in, and thus not especially different from the current situation where you opt into strict constructors using MooseX::StrictConstructor.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re: Should MooseX::StrictConstructor be part of Moose itself?
by Your Mother (Bishop) on Nov 14, 2013 at 04:14 UTC

    I like this idea in spirit. I dislike object creation allowing arguments that are silently discarded. Bad UI. Easy mistake for end user. Not sure about the practice. Including MooseX::StrictConstructor is not exactly a hardship… but not fun or an obvious thing to do either, so, ++ unless someone Moose-corish has compelling rationale against.

Re: Should MooseX::StrictConstructor be part of Moose itself?
by sundialsvc4 (Abbot) on Nov 16, 2013 at 00:16 UTC

    I would say that this sort of thing probably should be discussed in some kind of a “best practices” (or “highly-recommended possibilities”) section within the Moose documentation ... rather than trying to incorporate it into (“so there!!”) an already rather-weighty system.   We should, in our documentation, strive to guide the Gentle Reader, both to a proper recognition that these issues exist, and to some “really-good food for thought” concerning what to do.   Shove the issue into his face, then point him (directly...) to Strict, and to Slurpy.

    For one thing, we should be pragmatically mindful about the impact of “prior art.”   It’s too late to dictate what shall be done.   There’s already “too much Moose code out there in production.”   Even if we did now try to fold this particular feature “into Moose,” this act will not have so much impact today as it would have had before Moose seriously began to take off.   We can, and should, strive to influence future code, but there is already a build-up of legacy code here.   Human decisions are going to play a major part from now on, so we should strive to inform ... but, to mandate ... those decisions.

Re: Should MooseX::StrictConstructor be part of Moose itself?
by einhverfr (Friar) on Nov 17, 2013 at 12:48 UTC

    I don't know. The current status quo makes it very easy to "glue" different layers of code together assuming certain contracts, and allow those contracts to be extensible later on (handling optional extensions if one wants).

    Now, "easy glue" has a number of traps, but opting into the status quo today would make my life a lot harder. For example there are times where I want to say "given this data structure, take the relevant subset and create an object from it" and Moose is currently very good at doing that. Moreover if Moo were to adopt this behavior too, I would have to write additional constructors for handling that case on every class.

    As I see it, Moose has a large number of ways of ensuring a flexible yet robust software contract besides this. You have type constraints, required attributes, and more. Since these are remarkably helpful I don't see why this should be the default behavior.

Re: Should MooseX::StrictConstructor be part of Moose itself?
by boftx (Deacon) on Nov 20, 2013 at 04:01 UTC

    Thank you to those who have responded to this musing. Although small, the response has been balanced and informative.

    After reading the replies, and reading up on MooseX::SlurpyConstructor, I would say that having the StrictConstructor behavior as a default, with an opt-out capability, would be a Good Thing(tm).

    From what I can tell, SlurpyConstructor was meant to be a less painful way to transition to MooseX::StrictConstructor in as much as one could include SlurpyConstructor and then issue warnings or take other steps if the "slurpy" attribute contained anything. This would of course presume that someone was paying attention to log files or emails.

    Personally, I'd just as soon go straight to StrictConstructor, test everything I could manually, and make changes as indicated by the exception messages received and be done with it. It is difficult for me to envision a use case where the "slurpy" behavior would actually be desired as part of a proper design.

    I doubt that the change I am advocating will ever occur given the amount of existing code in the wild now, but I hope that this has given those in the Moose Cabal, along with others, food for thought.

    It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1062524]
Approved by marto
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2018-03-17 15:40 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (224 votes). Check out past polls.