Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Ovid,

    Your question was answered on the mailing list [perl.org], it is not a bug and this issue has been discussed many times before over the last 3 years and we always come back to the same conclusion that a default for is is too much DWIMery.

    - Stevan

    • Thanks Stevan. No worries. I personally accept some DWIMery for what I envision as the common use case and accept that this sometimes make the syntax a bit more difficult for other cases, but at the end of the day, it's no big deal. Now that I understand this, I can deal with it, though a better error message might help (though at the cost of tracking this information, I've no idea if the net impact for this use case is beneficial).

      My apologies for raising an issue that's been raised before. I googled q

      • I personally accept some DWIMery for what I envision as the common use case and accept that this sometimes make the syntax a bit more difficult for other cases, but at the end of the day, it's no big deal.

        I understand your issue, but the number of possible combinations available for has is huge and when you start introducing default values for any of them you are heading down a very slippery slope. As you said in the comment above, you would prefer ro, but some people would expect rw, while still others would rather we support PBP-style accessors and then there is the semi-affordance crowd, and the public reader/private writer crowd, the list can go on and on. In my mind the only solution to all these differing (and equally valid) viewpoints is to favor none of them but allow all of them (which is exactly what Moose does). I think this embodies the spirit of TIMTOWTDI and is therefore (IMO at least) the most "perlish".

        Now that I understand this, I can deal with it, though a better error message might help (though at the cost of tracking this information, I've no idea if the net impact for this use case is beneficial).

        The problem with an error message is the same as trying to decide which default to use. Someone wins and someone looses. If I throw a warning when there is no value for 'is', then someone who has a legit use would have to suppress the error. Personally i think that the best solution here is Perl::Critic (same as the role method issue you brought up). Perl::Critic is entirely optional, very configurable and does not impose any runtime or compile-time penalties.

        >My apologies for raising an issue that's been raised before. I googled quite a bit for this, but never found the right combination of keywords.

        Unfortunately most of this discussion has actually taken place on #moose and therefore is not easily google-able.

        - Stevan

        • The idea of a better error message would actually be to trap the error and see if there was an attribute up the tree which didn't have any accessor defined for it and warn on that. That being said, it seems like it might be too much work for too little benefit.