You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If someone has custom accessors with coercion, currently the accessor won't
be called and the coercion thus won't be applied to constructor arguments,
which are directly blessed into the object hash.
Should they be called if we can detect custom accessors? If not, we should
document a pattern to help people do this, such as in BUILD:
sub BUILD {
my $self = shift;
$self->$_( $self->{$_} ) for qw/baz bam/; # coerce custom
}
I worry that there's no way to know that a custom accessor is also a
mutator, so leaving it to the end user in BUILD might be the safest thing.
This would be nice (it would be Moo compatible), except that as things are currently written, it would prevent read-only custom accessors. They'd have to be generated within Class::Tiny itself.
I am also curious about this as part of cxw42/Class-Tiny-ConstrainedAccessor#4. Even letting BUILD know which parameters were indeed constructor parameters would be helpful (always just the actual hashtable keys in the blessed hashref, right?).
BUILD does get passed $args as a parameter. This only includes arguments passed to the constructor (technically it returns the hashref produced by BUILDARGS) and not defaults.
If someone has custom accessors with coercion, currently the accessor won't
be called and the coercion thus won't be applied to constructor arguments,
which are directly blessed into the object hash.
Should they be called if we can detect custom accessors? If not, we should
document a pattern to help people do this, such as in BUILD:
I worry that there's no way to know that a custom accessor is also a
mutator, so leaving it to the end user in BUILD might be the safest thing.
CC: @miyagawa
The text was updated successfully, but these errors were encountered: