Type::Tiny::Manual::Params - Online Linux Manual Page

Section : 3pm
Updated : 2021-02-24
Source : perl v5.32.1
Note : User Contributed Perl Documentation

NAME

Type::Tiny::Manual::Params − advanced information on Type::Params

MANUAL

To get started with Type::Params, please read Type::Tiny::Manual::UsingWithMoo which will cover a lot of the basics, even if you're not using Moo.

validate

and

validate_named

The generally recommended way of using Type::Params is this:

​  sub mysub {
​    state $check = compile( SIGNATURE );
​    my @args = $check−>( @_ );
​  }

But it is possible to do it in one call:

​  sub mysub {
​    my @args = validate( \@_, SIGNATURE );
​  }

There is also a validate_named

function which acts as a counterpart for

compile_named

This will generally be slower and less efficient than using compile

first because Type::Tiny can do a lot of optimizations in that first stage to make the second stage a lot faster. (And the results of

compile

get stored in the

state

variable so that only has to happen once.)

There is rarely a reason to use validate

and

validate_named

, but they exist if you want them.

multisig

Multisig allows you to allow multiple ways of calling a sub.

​ sub repeat_string {
​   state $check = multisig(
​     compile(
​       Int,
​       Str,
​     ),
​     compile_named(
​       { named_to_list => 1 },
​       count  => Int,
​       string => Str,
​     ),
​   );
​   
​   my ($count, $string) = $check−>(@_);
​   return $string x $count;
​ }
​ 
​ repeat_string(            "Hello",          42  );    # works
​ repeat_string(  string => "Hello", count => 42  );    # works
​ repeat_string({ string => "Hello", count => 42 });    # works
​ repeat_string( qr/hiya/ );                            # dies

It combines multiple checks and tries each until one works.

wrap_subs

and

wrap_methods

wrap_subs

turns the

compile

idea inside out.

Instead of this:

​ sub foobar {
​   state $check = compile(Int, Str);
​   my ($foo, $bar) = @_;
​   ...;
​ }

You do this:

​ sub foobar {
​   my ($foo, $bar) = @_;
​   ...;
​ }
​ wrap_subs foobar => [ Int, Str ];

Or this:

​ sub foobar {
​   my ($foo, $bar) = @_;
​   ...;
​ }
​ wrap_subs foobar => compile( Int, Str );

Mixed Named and Positional Parameters

This can be faked using positional parameters and a slurpy dictionary.

​ state $check = compile(
​   Int,
​   slurpy Dict[
​     foo => Int,
​     bar => Optional[Int],
​     baz => Optional[Int],
​   ],
​ );
​ 
​ @_ = (42, foo => 21);                 # ok
​ @_ = (42, foo => 21, bar  => 84);     # ok
​ @_ = (42, foo => 21, bar  => 10.5);   # not ok
​ @_ = (42, foo => 21, quux => 84);     # not ok

From Type::Params 1.009_002, head

and

tail

options are accepted, which provide another option for mixed named and positional arguments:

​ state $check = compile_named(
​   { head => [ Int ] },
​   foo => Int,
​   bar => Optional[Int],
​   baz => Optional[Int],
​   ],
​ );

The head

is shifted off

@_

before

@_

is considered as a hash. The

tail

is popped off

@_

before

@_

is considered as a hash.

Proper Signatures

Don't you wish your subs could look like this?

​  sub set_name (Object $self, Str $name) {
​    $self−>{name} = $name;
​  }

Well; here are a few solutions for sub signatures that work with Type::Tiny...

Zydeco

Zydeco is a Perl OO syntax toolkit with Type::Tiny support baked in throughout.

​  package MyApp {
​    use Zydeco;
​    
​    class Person {
​      has name ( type => Str );
​      
​      method rename (Str $new_name) {
​        printf("%s will now be called %s\n", $self−>name, $new_name);
​        $self−>name($new_name);
​      }
​      
​      coerce from Str via {
​        $class−>new(name => $_)
​      }
​    }
​    
​    class Company {
​      has owner ( type => 'Person' );
​    }
​  }
​  
​  my $acme = MyApp−>new_company(owner => "Robert");
​  $acme−>owner−>rename("Bob");

Kavorka

Kavorka is a sub signatures implementation written to natively use Type::Utils'

dwim_type

for type constraints, and take advantage of Type::Tiny's features such as inlining, and coercions.

​  method set_name (Str $name) {
​    $self−>{name} = $name;
​  }

Kavorka's signatures provide a lot more flexibility, and slightly more speed than Type::Params. (The speed comes from inlining almost all type checks into the body of the sub being declared.)

Kavorka also includes support for type checking of the returned value.

Kavorka can also be used as part of Moops, a larger framework for object oriented programming in Perl.

Function::Parameters

Function::Parameters offers support for Type::Tiny and MooseX::Types.

​  use Types::Standard qw( Str );
​  use Function::Parameters;
​  
​  method set_name (Str $name) {
​      $self−>{name} = $name;
​  }

Attribute::Contract

Both Kavorka and Function::Parameters require a relatively recent version of Perl. Attribute::Contract supports older versions by using a lot less magic.

You want Attribute::Contract 0.03 or above.

​  use Attribute::Contract −types => [qw/Object Str/];
​  
​  sub set_name :ContractRequires(Object, Str) {
​      my ($self, $name) = @_;
​      $self−>{name} = $name;
​  }

Attribute::Contract also includes support for type checking of the returned value.

Type::Params versus X

Params::Validate

Type::Params is not really a drop-in replacement for Params::Validate; the API differs far too much to claim that. Yet it performs a similar task, so it makes sense to compare them.

• Type::Params will tend to be faster if you've got a sub which is called repeatedly, but may be a little slower than Params::Validate for subs that are only called a few times. This is because it does a bunch of work the first time your sub is called to make subsequent calls a lot faster.

• Params::Validate doesn't appear to have a particularly natural way of validating a mix of positional and named parameters.

• Type::Utils allows you to coerce parameters. For example, if you expect a Path::Tiny object, you could coerce it from a string.

• If you are primarily writing object-oriented code, using Moose or similar, and you are using Type::Tiny type constraints for your attributes, then using Type::Params allows you to use the same constraints for method calls.

• Type::Params comes bundled with Types::Standard, which provides a much richer vocabulary of types than the type validation constants that come with Params::Validate. For example, Types::Standard provides constraints like ArrayRef[Int]

(an arrayref of integers), while the closest from Params::Validate is

ARRAYREF

, which you'd need to supplement with additional callbacks if you wanted to check that the arrayref contained integers. Whatsmore, Type::Params doesn't just work with Types::Standard, but also any other Type::Tiny type constraints.

Params::ValidationCompiler

Params::ValidationCompiler does basically the same thing as Type::Params.

• Params::ValidationCompiler and Type::Params are likely to perform fairly similarly. In most cases, recent versions of Type::Params seem to be slightly

faster, but except in very trivial cases, you're unlikely to notice the speed difference. Speed probably shouldn't be a factor when choosing between them.

• Type::Params's syntax is more compact:

​   state $check = compile(Object, Optional[Int], slurpy ArrayRef);

Versus:

​   state $check = validation_for(
​      params => [
​         { type => Object },
​         { type => Int,      optional => 1 },
​         { type => ArrayRef, slurpy => 1 },
​      ],
​   );

• Params::ValidationCompiler probably has slightly better exceptions.

NEXT STEPS

Here's your next step:

• Type::Tiny::Manual::NonOO Type::Tiny in non-object-oriented code.

AUTHOR

Toby Inkster <tobyink@cpan.org>.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

DISCLAIMER OF WARRANTIES

THIS PACKAGE IS PROVIDED ‟AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Johanes Gumabo

Data Size : 30,362 byte

man-Type::Tiny::Manual::Params.3pmBuild :

2025-03-22, 13:26

Visitor Screen :

Visitor Counter ( page / site )

11 / 1,208,765

Visitor ID :

Visitor IP :

18.189.194.34

Visitor Provider :

AMAZON-02

Provider Position ( lat x lon )

39.962500

-83.006100

Provider Accuracy Radius ( km )

1000

Provider City :

Columbus

Provider Province :

Ohio

Provider Country :

United States

Provider Continent :

North America

Visitor Recorder : Version :

Visitor Recorder : Library :

Online Linux Manual Page : Version :

Online Linux Manual Page - Fedora.40 - march=x86-64 - mtune=generic - 25.03.22

Online Linux Manual Page : Library :

lib_c - 24.10.03 - march=x86-64 - mtune=generic - Fedora.40

Online Linux Manual Page : Library :

lib_m - 24.10.03 - march=x86-64 - mtune=generic - Fedora.40

Data Base : Version :

Online Linux Manual Page Database - 24.04.13 - march=x86-64 - mtune=generic - fedora-38

Data Base : Library :

lib_c - 23.02.07 - march=x86-64 - mtune=generic - fedora.36

Very long time ago, I have the best tutor, Wenzel Svojanovsky. If someone knows the email address of Wenzel Svojanovsky, please send an email to johanesgumabo@gmail.com.

Help me, linux0001.com will expire on July 16, 2025. I have no money to renew it. View detail

If error, please print screen and send to johanes_gumabo@yahoo.co.id
Under development. Support me via PayPal.

ERROR :

Need New Coding

(parse_manual_page_|254|Type::Tiny::Manual::Params.3pm|36/37|el══─{─══.|.el══─{─══. ds -- \|\(em\| ) (htmlprn|160|Type::Tiny::Manual::Params.3pm|36/37|.el══─{─══. ds -- — |.el══─{─══. ds -- \|\(em\| ) (parse_manual_page_|254|Type::Tiny::Manual::Params.3pm|43|br══─}─══|'br══─}─══ ) (htmlprn|160|Type::Tiny::Manual::Params.3pm|43|'br══─}─══ |'br══─}─══ )