Re^3: RFC: Inline::Blocks or inline as a keyword?

[tobyink]

Each type constraint knows how to generate a string of Perl code for validating a value, given a variable name for the value.

For example:

$ perl -MDevel::Hide=Ref::Util::XS,Type::Tiny::XS -MTypes::Standard=-t
+ypes -E'say HashRef->inline_check(q/$myvar/)'
Devel::Hide hides Ref/Util/XS.pm, Type/Tiny/XS.pm
(ref($myvar) eq 'HASH')

So the ArrayRef[HashRef] type constraint can use that when generating a longer bit of code to validate an arrayref of hashrefs:

$ perl -MDevel::Hide=Ref::Util::XS,Type::Tiny::XS -MTypes::Standard=-t
+ypes -E'say ArrayRef->of(HashRef)->inline_check(q/$myvar/)'
Devel::Hide hides Ref/Util/XS.pm, Type/Tiny/XS.pm
do { (ref($myvar) eq 'ARRAY') and do { my $ok = 1; for my $i (@{$myvar
+}) { ($ok = 0, last) unless (ref($i) eq 'HASH') }; $ok } }

[LanX]

Are you saying you are dynamically generating code for your type checks which is eval'ed?

Not sure if that's the meaning of "inlining" in this thread.

Probably I'm missing your point...

[tobyink]

The ArrayRef and Int type constraints are smart enough to know how to combine to make an ArrayRef[Int] type check which inlines the Int check inside a loop over the array. This inline code is evaled within a sub { ... } to create a single coderef which checks that a value is an arrayref, and all elements in the arrayref are integers.

That code can also be retrieved as a string for inlining into larger coderefs like constructors, etc.