MooseX...uctured(3pm)

✨ okay so this is MooseX::Types::Structured(3pm), pulled straight from the User Contributed Perl Documentation, and bestie we are gonna get so good at structured type constraints together ✨

💖 NAME 💖

MooseX::Types::Structured — Structured Type Constraints for Moose. that's the whole vibe. periodt.

🎀 VERSION 🎀

version 0.36 🫶

🌸 SYNOPSIS 🌸

okay so here's the example usage for this module, and honestly it's giving main character energy:

package Person;

use Moose;
use MooseX::Types::Moose qw(Str Int HashRef);
use MooseX::Types::Structured qw(Dict Tuple Optional);

## A name has a first and last part, but middle names are not required
has name => (
    isa=>Dict[
        first => Str,
        last => Str,
        middle => Optional[Str],
    ],
);

## description is a string field followed by a HashRef of tagged data.
has description => (
  isa=>Tuple[
    Str,
    Optional[HashRef],
 ],
);

## Remainder of your class attributes and methods

then you can actually make one of these objects, like:

my $john = Person->new(
    name => {
        first => 'John',
        middle => 'James'
        last => 'Napiorkowski',
    },
    description => [
        'A cool guy who loves Perl and Moose.', {
            married_to => 'Vanessa Li',
            born_in => 'USA',
        };
    ]
);

or, alternatively:

my $vanessa = Person->new(
    name => {
        first => 'Vanessa',
        last => 'Li'
    },
    description => ['A great student!'],
);

but 💀 all of these would cause a constraint error for the "name" attribute, no cap:

## Value for 'name' not a HashRef
Person->new( name => 'John' );

## Value for 'name' has incorrect hash key and missing required keys
Person->new( name => {
    first_name => 'John'
});

## Also incorrect keys
Person->new( name => {
    first_name => 'John',
    age => 39,
});

## key 'middle' incorrect type, should be a Str not a ArrayRef
Person->new( name => {
    first => 'Vanessa',
    middle => [1,2],
    last => 'Li',
});

and these ones? yeah they'd cause a constraint error for the "description" attribute too 🙈

## Should be an ArrayRef
Person->new( description => 'Hello I am a String' );

## First element must be a string not a HashRef.
Person->new (description => [{
    tag1 => 'value1',
    tag2 => 'value2'
}]);

Please see the test cases for more examples. (the tests are iconic, go look 👑)

🦋 DESCRIPTION 🦋

A structured type constraint is a totally standard container Moose type constraint — think "ArrayRef" or "HashRef" — except it's been upgraded to let you explicitly name all the allowed type constraints inside the structure. glow up fr. the generalized form is:

TypeConstraint[@TypeParameters or %TypeParameters]

Where "TypeParameters" is an array reference or hash references of Moose::Meta::TypeConstraint objects. (yes, actual objects, not just vibes ✨)

This type library is what enables structured type constraints. It's built on top of the MooseX::Types library system, so if you're not familiar with that one, you should go review its documentation first, bestie. it's prerequisite reading, iykyk.

🌈 Comparing Parameterized types to Structured types 🌈

Parameterized constraints are built right into core Moose, and you're probably already besties with the type constraints "HashRef" and "ArrayRef". Structured types do a similar thing, so the syntax is likewise similar. For example, you could define a parameterized constraint like:

subtype ArrayOfInts,
 as ArrayRef[Int];

which would constrain a value to something like [1,2,3,...] and so on. On the other hand, a structured type constraint explicitly names all of its allowed 'internal' type parameter constraints. so for this example:

subtype StringFollowedByInt,
 as Tuple[Str,Int];

it would constrain its value to things like "['hello', 111]" but "['hello', 'world']" would fail, and so would "['hello', 111, 'world']" and so on. here's another example:

    package MyApp::Types;

use MooseX::Types -declare [qw(StringIntOptionalHashRef)];
use MooseX::Types::Moose qw(Str Int);
use MooseX::Types::Structured qw(Tuple Optional);

subtype StringIntOptionalHashRef,
 as Tuple[
    Str, Int,
    Optional[HashRef]
 ];

This defines a type constraint that validates values like:

['Hello', 100, {key1 => 'value1', key2 => 'value2'}];
['World', 200];

Notice that the last type constraint in the structure is optional 👀 that's enabled via the helper "Optional" type constraint, which is a variation of the core Moose type constraint "Maybe". The big difference is that "Optional" type constraints are required to validate if they exist, while "Maybe" permits undefined values. so like, the following example would not validate:

StringIntOptionalHashRef->validate(['Hello Undefined', 1000, undef]);

Please note the subtle difference between undefined and null, bestie — they are NOT the same thing and the way people conflate them is giving chaos 😭. If you wish to allow both null and undefined, you should use the core Moose "Maybe" type constraint instead:

package MyApp::Types;

use MooseX::Types -declare [qw(StringIntMaybeHashRef)];
use MooseX::Types::Moose qw(Str Int Maybe);
use MooseX::Types::Structured qw(Tuple);

subtype StringIntMaybeHashRef,
 as Tuple[
    Str, Int, Maybe[HashRef]
 ];

That one would validate the following:

['Hello', 100, {key1 => 'value1', key2 => 'value2'}];
['World', 200, undef];
['World', 200];

Structured constraints are not limited to arrays, thank god. You can define a structure against a "HashRef" with the "Dict" type constraint, like this:

subtype FirstNameLastName,
 as Dict[
    firstname => Str,
    lastname => Str,
 ];

This would constrain a "HashRef" that validates something like:

{firstname => 'Christopher', lastname => 'Parsons'};

but every single one of the following would fail validation 💀:

## Incorrect keys
{first => 'Christopher', last => 'Parsons'};

## Too many keys
{firstname => 'Christopher', lastname => 'Parsons', middlename => 'Allen'};

## Not a HashRef
['Christopher', 'Parsons'];

These structures can be as simple or as elaborate as you wish. You can even combine various structured, parameterized and simple constraints all together, which is honestly so fun:

subtype Crazy,
 as Tuple[
    Int,
    Dict[name=>Str, age=>Int],
    ArrayRef[Int]
 ];

Which would match:

[1, {name=>'John', age=>25},[10,11,12]];

Please notice how the type parameters can be visually arranged to your liking, to improve the clarity of your meaning ✨ you don't need to run them all together onto a single line. Additionally, since the "Dict" type constraint defines a hash constraint, the key order is not meaningful. for example:

subtype AnyKeyOrder,
  as Dict[
    key1=>Int,
    key2=>Str,
    key3=>Int,
 ];

Would validate both:

{key1 => 1, key2 => "Hi!", key3 => 2};
{key2 => "Hi!", key1 => 100, key3 => 300};

As you would expect, since underneath it's just a plain old Perl hash at work. no cap, it's just a hash.

🧚 Alternatives 🧚

You should exercise some care as to whether or not your complex structured constraints would be better off contained by a real object, like in the following example:

package MyApp::MyStruct;
use Moose;

## lazy way to make a bunch of attributes
has $_ for qw(full_name age_in_years);

package MyApp::MyClass;
use Moose;

has person => (isa => 'MyApp::MyStruct');

my $instance = MyApp::MyClass->new(
    person=>MyApp::MyStruct->new(
        full_name => 'John',
        age_in_years => 39,
    ),
);

This method may take some additional time to set up, but it will give you more flexibility. However — and this is the slay part — structured constraints are highly compatible with this method, granting some interesting possibilities for coercion. try:

package MyApp::MyClass;

use Moose;
use MyApp::MyStruct;

## It's recommended your type declarations live in a separate class in order
## to promote reusability and clarity.  Inlined here for brevity.

use MooseX::Types::DateTime qw(DateTime);
use MooseX::Types -declare [qw(MyStruct)];
use MooseX::Types::Moose qw(Str Int);
use MooseX::Types::Structured qw(Dict);

## Use class_type to create an ISA type constraint if your object doesn't
## inherit from Moose::Object.
class_type 'MyApp::MyStruct';

## Just a shorter version really.
subtype MyStruct,
 as 'MyApp::MyStruct';

## Add the coercions.
coerce MyStruct,
 from Dict[
    full_name=>Str,
    age_in_years=>Int
 ], via {
    MyApp::MyStruct->new(%$_);
 },
 from Dict[
    lastname=>Str,
    firstname=>Str,
    dob=>DateTime
 ], via {
    my $name = $_->{firstname} .' '. $_->{lastname};
    my $age = DateTime->now - $_->{dob};

    MyApp::MyStruct->new(
        full_name=>$name,
        age_in_years=>$age->years,
    );
 };

has person => (isa=>MyStruct);

This would allow you to instantiate with something like:

my $obj = MyApp::MyClass->new( person => {
    full_name=>'John Napiorkowski',
    age_in_years=>39,
});

Or even:

my $obj = MyApp::MyClass->new( person => {
    lastname=>'John',
    firstname=>'Napiorkowski',
    dob=>DateTime->new(year=>1969),
});

If you are not familiar with how coercions work, check out the Moose cookbook entry Moose::Cookbook::Recipe5 for an explanation. The section "Coercions" has additional examples and discussion. 🫶

⭐ Subtyping a Structured type constraint ⭐

You need to exercise some care when you try to subtype a structured type, like in this example:

subtype Person,
 as Dict[name => Str];

subtype FriendlyPerson,
 as Person[
    name => Str,
    total_friends => Int,
 ];

This will actually work BUT you have to take care that the subtype has a structure that does not contradict the structure of its parent. For now the above works, but I will clarify the syntax for this at a future point, so it's recommended to avoid it (should not really be needed so much anyway). For now this is supported in an EXPERIMENTAL way 🧪. Your thoughts, test cases and patches are welcomed for discussion. If you find a good use for this, please let me know.

💫 Coercions 💫

Okay so real talk: coercions rn only work for 'one level' deep. Like, that's the vibe, that's the limit. Here's what you can do:

subtype Person,
 as Dict[
    name => Str,
    age => Int
 ];

 subtype Fullname,
  as Dict[
     first => Str,
     last => Str
  ];

 coerce Person,
  ## Coerce an object of a particular class
  from BlessedPersonObject, via {
     +{
         name=>$_->name,
         age=>$_->age,
     };
  },

  ## Coerce from [$name, $age]
  from ArrayRef, via {
     +{
         name=>$_->[0],
         age=>$_->[1],
     },
  },
  ## Coerce from {fullname=>{first=>...,last=>...}, dob=>$DateTimeObject}
  from Dict[fullname=>Fullname, dob=>DateTime], via {
     my $age = $_->dob - DateTime->now;
     my $firstn = $_->{fullname}->{first};
     my $lastn = $_->{fullname}->{last}
     +{
         name => $_->{fullname}->{first} .' '. ,
         age =>$age->years
     }
  };

And that should just work as expected. 💅

But — and this is the part where you go "wait what" 😭 — if there are any 'inner' coercions, like a coercion on Fullname or on DateTime, those inner coercions won't currently get activated. Yeah. Not yet. It's giving "future feature" energy.

Please see the test 07-coerce.t for a more detailed example. Discussion on extending coercions to support this welcome on the Moose development channel or mailing list 🫶 — come hang out fr.

---

🌀 Recursion 🌀

Newer versions of MooseX::Types support recursive type constraints. Translation: you can include a type constraint as a contained type constraint of itself. Types within types within types, inception-style 🧚✨. For example:

subtype Person,
 as Dict[
     name=>Str,
     friends=>Optional[
         ArrayRef[Person]
     ],
 ];

This would declare a Person subtype that contains a name and an optional ArrayRef of Persons who are friends, as in:

{
    name => 'Mike',
    friends => [
        { name => 'John' },
        { name => 'Vincent' },
        {
            name => 'Tracey',
            friends => [
                { name => 'Stephenie' },
                { name => 'Ilya' },
            ],
        },
    ],
};

Look at that friend group 🌸 iconic.

⚠️ Please take care to make sure the recursion node is either Optional, or declare a union with an non-recursive option such as:

subtype Value
 as Tuple[
     Str,
     Str|Tuple,
 ];

Which validates:

[
    'Hello', [
        'World', [
            'Is', [
                'Getting',
                'Old',
            ],
        ],
    ],
]

Otherwise you will define a subtype that is impossible to validate since it is infinitely recursive 💀 — like, no cap, it will never terminate. For more information about defining recursive types, please see the documentation in MooseX::Types and the test cases.

---

👑 TYPE CONSTRAINTS 👑

This type library defines the following constraints. Bestie, buckle up 🎀

🍓 Tuple[@constraints]

This defines an ArrayRef based constraint which allows you to validate a specific list of contained constraints. For example:

Tuple[Int,Str]; ## Validates [1,'hello']
Tuple[Str|Object, Int]; ## Validates ['hello', 1] or [$object, 2]

The Values of @constraints should ideally be MooseX::Types declared type constraints. We do support 'old style' Moose string based constraints to a limited degree but these string type constraints are considered deprecated. There will be limited support for bugs resulting from mixing string and MooseX::Types in your structures. If you encounter such a bug and really need it fixed, we will required a detailed test case at the minimum. 😤 (yes, "we will required", our typo, our truth)

💜 Dict[%constraints]

This defines a HashRef based constraint which allowed you to validate a specific hashref. For example:

Dict[name=>Str, age=>Int]; ## Validates {name=>'John', age=>39}

The keys in %constraints follow the same rules as @constraints in the above section. Same energy, different container 🫶

🌈 Map[ $key_constraint, $value_constraint ]

This defines a HashRef-based constraint in which both the keys and values are required to meet certain constraints. For example, to map hostnames to IP addresses, you might say:

Map[ HostName, IPAddress ]

The type constraint would only be met if every key was a valid HostName and every value was a valid IPAddress. No half-validating, no slacking, every single pair has to pass the vibe check 🔥

🦋 Optional[$constraint]

This is primarily a helper constraint for Dict and Tuple type constraints. What this allows is for you to assert that a given type constraint is allowed to be null (but NOT undefined). If the value is null, then the type constraint passes — but if the value is defined it must validate against the type constraint. This makes it easy to make a Dict where one or more of the keys doesn't have to exist, or a tuple where some of the values are not required. For example:

subtype Name() => as Dict[
    first=>Str,
    last=>Str,
    middle=>Optional[Str],
];

...creates a constraint that validates against a hashref with the keys 'first' and 'last' being strings and required, while an optional key 'middle' is must be a string if it appears but doesn't have to appear. So in this case both the following are valid:

{first=>'John', middle=>'James', last=>'Napiorkowski'}
{first=>'Vanessa', last=>'Li'}

If you use the Maybe type constraint instead, your values will also validate against undef, which may be incorrect for you. 🙈 Choose wisely bestie.

---

📦 EXPORTABLE SUBROUTINES 📦

This type library makes available for export the following subroutines 💖

🎀 slurpy

Structured type constraints by their nature are closed — that is, validation will depend on an exact match between your structure definition and the arguments to be checked. Sometimes you might wish for a slightly looser amount of validation. For example, you may wish to validate the first 3 elements of an array reference and allow for an arbitrary number of additional elements. At first thought you might think you could do it this way:

#  I want to validate stuff like: [1,"hello", $obj, 2,3,4,5,6,...]
subtype AllowTailingArgs,
 as Tuple[
   Int,
   Str,
   Object,
   ArrayRef[Int],
 ];

However what this will actually validate are structures like this:

[10,"Hello", $obj, [11,12,13,...] ]; # Notice element 4 is an ArrayRef

Not me thinking that would work 😭. In order to allow structured validation of, "and then some", arguments, you can use the slurpy method against a type constraint. For example:

use MooseX::Types::Structured qw(Tuple slurpy);

subtype AllowTailingArgs,
 as Tuple[
   Int,
   Str,
   Object,
   slurpy ArrayRef[Int],
 ];

This will now work as expected, validating ArrayRef structures such as:

[1,"hello", $obj, 2,3,4,5,6,...]

Slay. ✨ But a few caveats apply:

• First, the slurpy type constraint must be the last one in the list of type constraint parameters. Last. Final. End of the line 🚫
• Second, the parent type of the slurpy type constraint must match that of the containing type constraint. That means that a Tuple can allow a slurpy ArrayRef (or children of ArrayRefs, including another Tuple) and a Dict can allow a slurpy HashRef (or children/subtypes of HashRef, also including other Dict constraints). Matching parents only, iykyk 💅

Please note the technical way this works 'under the hood' is that the slurpy keyword transforms the target type constraint into a coderef. Please do not try to create your own custom coderefs — always use the slurpy method. The underlying technology may change in the future but the slurpy keyword will be supported. Periodt. 👑

---

💀 ERROR MESSAGES 💀

Error reporting has been improved to return more useful debugging messages 🔥 Now I will stringify the incoming check value with Devel::PartialDump so that you can see the actual structure that is tripping up validation. Also, I report the 'internal' validation error, so that if a particular element inside the Structured Type is failing validation, you will see that. There's a limit to how deep this internal reporting goes, but you shouldn't see any of the "failed with ARRAY(XXXXXX)" that we got with earlier versions of this module. Glow up achieved ✨

This support is continuing to expand, so it's best to use these messages for debugging purposes and not for creating messages that 'escape into the wild' such as error messages sent to the user. ⚠️ Like, these are backstage messages, not user-facing ones, bestie.

Please see the test 12-error.t for a more lengthy example. Your thoughts and preferable tests or code patches very welcome! 🫶💖

✨ EXAMPLES ✨

okay bestie, here are some extra example usages for structured types 💖 All of these also live in the t/examples.t test, and yes — your contributions are welcomed too 🫶

---

🦋 Normalize a HashRef 🦋

So picture this: you need a hashref to conform to a canonical structure, but you also have to accept a whole bunch of different incoming structures 😭 You can normalize using the Dict type constraint and coercions. This example also shows structured types mixed with other MooseX::Types libraries ✨

package Test::MooseX::Meta::TypeConstraint::Structured::Examples::Normalize;

use Moose;
use DateTime;

use MooseX::Types::Structured qw(Dict Tuple);
use MooseX::Types::DateTime qw(DateTime);
use MooseX::Types::Moose qw(Int Str Object);
use MooseX::Types -declare => [qw(Name Age Person)];

subtype Person,
 as Dict[
     name=>Str,
     age=>Int,
 ];

coerce Person,
 from Dict[
     first=>Str,
     last=>Str,
     years=>Int,
 ], via { +{
    name => "$_->{first} $_->{last}",
    age => $_->{years},
 }},
 from Dict[
     fullname=>Dict[
         last=>Str,
         first=>Str,
     ],
     dob=>DateTime,
 ],
 ## DateTime needs to be inside of single quotes here to disambiguate the
 ## class package from the DataTime type constraint imported via the
 ## line "use MooseX::Types::DateTime qw(DateTime);"
 via { +{
    name => "$_->{fullname}{first} $_->{fullname}{last}",
    age => ($_->{dob} - 'DateTime'->now)->years,
 }};

has person => (is=>'rw', isa=>Person, coerce=>1);

And now you can instantiate with all the following 👑💅

__PACKAGE__->new(
    person=>{
        name=>'John Napiorkowski',
        age=>39,
    },
);

__PACKAGE__->new(
    person=>{
        first=>'John',
        last=>'Napiorkowski',
        years=>39,
    },
);

__PACKAGE__->new(
    person=>{
        fullname => {
            first=>'John',
            last=>'Napiorkowski'
        },
        dob => 'DateTime'->new(
            year=>1969,
            month=>2,
            day=>13
        ),
    },
);

This technique is a way to support various ways to instantiate your class in a clean and declarative way 🌸 fr fr, it's giving "organized and iconic."

---

💖 SEE ALSO 💖

The following modules or resources may be of interest 👀

• Moose
• MooseX::Types
• Moose::Meta::TypeConstraint
• MooseX::Meta::TypeConstraint::Structured

---

🫶 SUPPORT 🫶

Bugs may be submitted through the RT bug tracker at https://rt.cpan.org/Public/Dist/Display.html?Name=MooseX-Types-Structured (or bug-MooseX-Types-Structured@rt.cpan.org) 🐛✨

There is also a mailing list available for users of this distribution, at http://lists.perl.org/list/moose.html 💌

There is also an irc channel available for users of this distribution, at #moose on irc.perl.org (irc://irc.perl.org/#moose) 💬🔥

---

👑 AUTHORS 👑

• 🌟 John Napiorkowski — jjnapiork@cpan.org
• 🌟 Florian Ragwitz — rafl@debian.org
• 🌟 יובל קוג'מן (Yuval Kogman) — nothingmuch@woobling.org
• 🌟 Tomas (t0m) Doran — bobtfish@bobtfish.net
• 🌟 Robert Sedlacek — rs@474.at

---

🌈 CONTRIBUTORS 🌈

• 💜 Karen Etheridge — ether@cpan.org
• 💜 Ricardo Signes — rjbs@cpan.org
• 💜 Dave Rolsky — autarch@urth.org
• 💜 Ansgar Burchardt — ansgar@43-1.org
• 💜 Stevan Little — stevan.little@iinteractive.com
• 💜 arcanez — justin.d.hunter@gmail.com
• 💜 Jesse Luehrs — doy@tozt.net
• 💜 D. Ilmari Mannsåker — ilmari@cpan.org

---

🎀 COPYRIGHT AND LICENSE 🎀

This software is copyright (c) 2008 by John Napiorkowski.

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

---

and that's the whole page, bestie 🫶 this one came from perl v5.42.0, dated 2017-05-10, under the MooseX...uctured(3pm) name — mwah 💋✨