-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small change for MooseX::Attribute::TypeConstraint::CustomizeFatal #101
base: master
Are you sure you want to change the base?
Conversation
The change in coverage is alarming; it would be nice to see these changes covered by tests. |
The weird part is that there is no actual behavior change beyond a method that by default ignores the extra argument. So the coverage change is misleading. On Sun, Apr 26, 2015 at 6:25 PM, Karen Etheridge [email protected]
|
I agree with Dahut! |
This is apparently for avar/moosex-attribute-typeconstraint-customizefatal#1 |
@karenetheridge Do you mean that this coveralls is telling about the decreased coverage for avar's module? |
@Sweet-kid I was just adding a cross-reference to the other PR that this is meant to go with, since it was not clear. |
I think it would be helpful to modify the argument list in the sub definition (https://github.com/Sweet-kid/Moose/blob/master/lib/Moose/Meta/Attribute.pm#L45), so it's clear what the extra argument is meant to be. |
Also, shouldn't this extra argument be passed in all the places where _inline_throw_exception is called? (Also, please add something to Changes.) |
e79a7d8
to
d45b381
Compare
I'm just passing one more argument to _inline_throw_exception. In MooseX::Attribute::TypeConstraint::CustomizeFatal, I'm overriding _inline_throw_exception & using this argument to initialize attribute's value to the default value.