Type::API::Constraint::Constructor

Interface

This interface can be implemented as a class method for a type constraint class, or as an object method for a factory object of some sort.

$implementation->new(%spec)

Returns an object implementing the Type::API::Constraint interface. The specification allows the following keys. Each is OPTIONAL . Implementations MAY accept other keys in addition to those given below.

constraint

The heart of the type constraint; a function (coderef) to check a value and return true/false. When this function is called, the value to be tested is available as the global variable $_ and is also passed as the first argument to the function.

This is optional, and if omitted, implementations MUST assume a function that always returns true. Implementations MUST NOT ignore the constraint function if one is provided, and MUST throw an exception if the constraint function is not acceptable for some reason.

parent

Another type constraint which the new type will be a child of. All values passing the child constraint, must also pass the parent constraint; the constraint function (above) is not even called if a value does not pass the parent constraint.

Implementations MUST NOT ignore the parent if one is provided, and MUST throw an exception if the parent type is not acceptable.

name

An optional name for the type constraint. The implementation MAY impose naming restrictions on constraints. Implementations providing only anonymous type constraints SHOULD silently ignore this parameter.

message

A function (coderef) to generate a message (suitable for returning from get_message ) for a value, and return it as a string. The value is available as the global variable $_ and is also passed as the first argument to the function.

Implementations not supporting custom messages SHOULD silently ignore this, and use their own logic to return a string from get_message .

inlined

A function (coderef) to generate a string of code capable to checking a value. This function is called with two parameters - the first is a reference back to the type constraint itself; the second is a string representing the name of a variable. The returned code is expected to be self-contained, and encompass checks for the parent type constraint too (if any).

Implementations not supporting inlining SHOULD silently ignore this.

See Also

Implementations

The following CPAN classes are known to implement Type::API::Constraint::Constructor:

• Moose::Meta::TypeConstraint (and its subclasses)
• MooseX::Meta::TypeDecorator
• Type::Tiny (and its subclasses)

The following CPAN classes implement variations of this interface with minor differences:

• Mouse::Meta::TypeConstraint - does not set global $_ for message.
• MouseX::Meta::TypeDecorator - does not set global $_ for message.
• Specio::Constraint::Simple (and several other classes in the Specio distribution) - does not set global $_ for message or constraint.