How can I lift an attribute constraint depending on another attribute from a trigger into a type refinement?

79 Views Asked by At

This works:

use Moops;
class Foo :ro {
    use Types::Common::Numeric qw(PositiveOrZeroInt);
    has from => required => true, isa => PositiveOrZeroInt;
    has to => required => true, isa => PositiveOrZeroInt, trigger => method($to) {
        die 'must be from ≤ to' unless $self->from <= $to
    };
}
Foo->new(from => 0, to => 1); # ok
Foo->new(from => 1, to => 0); # "must be from ≤ to at …"

I would like to be able to make the constraint part of the type, somehow.

use Moops;
class Bar :ro {
    use Types::Common::Numeric qw(PositiveOrZeroInt);
    has from => required => true, isa => PositiveOrZeroInt;
    has to => required => true, isa => PositiveOrZeroInt->where(sub {
        $self->from <= $_
    });
}
Bar->new(from => 0, to => 1);
# Global symbol "$self" requires explicit package name
# (did you forget to declare "my $self"?)

I checked that the where sub only receives one parameter.

1

There are 1 best solutions below

0
tobyink On

If you wanted to do it in a type check, you could combine the two attributes into one attribute which would be an arrayref holding both numbers.

use Moops;

class Foo :ro {
    use Types::Standard qw(Tuple);
    use Types::Common::Numeric qw(PositiveOrZeroInt);
    
    has from_and_to => (
        required => true,
        isa      => Tuple->of(PositiveOrZeroInt, PositiveOrZeroInt)->where(sub {
            $_->[0] <= $_->[1];
        }),

        # Provide `from` and `to` methods to fetch values
        handles_via => 'Array',
        handles => {
            'from' => [ get => 0 ],
            'to'   => [ get => 1 ],
        },
    );
    
    # Allow `from` and `to` to be separate in the constructor
    method BUILDARGS {
        my %args = ( @_==1 ? %{$_[0]} : @_ );
        $args{from_and_to} ||= [ $args{from}, $args{to} ];
        \%args;
    }
}

Foo->new(from => 0, to => 1); # ok
Foo->new(from => 1, to => 0); # "must be from ≤ to at …"

I wouldn't do it in a type check though. I'd do it in BUILD (no, not BUILDARGS) if the attribute were read-only, or trigger if it were read-write.