File: UsingWithMite.pod

package info (click to toggle)
libtype-tiny-perl 2.002001-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 3,948 kB
  • sloc: perl: 14,610; makefile: 2; sh: 1
file content (187 lines) | stat: -rw-r--r-- 4,934 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
=pod

=encoding utf-8

=head1 NAME

Type::Tiny::Manual::UsingWithMite - how to use Type::Tiny with Mite

=head1 MANUAL

L<Mite> takes an unorthodox approach to object-oriented code. When you first
start a project with Mite (which we'll assume is called Your::Project), Mite
will create a module called Your::Project::Mite for you.

Then all your classes use code like:

   package Your::Project::Widget;
   
   use Your::Project::Mite -all;
   
   has name => (
      is => ro,
      isa => 'Str',
   );
   
   has id => (
      is => ro,
      isa => 'PositiveInt',
   );
   
   signature_for warble => (
      named => [
         foo   => 'Int',
         bar   => 'ArrayRef',
      ],
   );
   
   sub warble {
      my ( $self, $arg ) = @_;
      printf( "%s: %d\n", $self->name, $arg->foo );
      return;
   }
   
   1;

After writing or editing each class or role, you run the command
C<< mite compile >> and Mite will output a collection of compiled Perl
classes which have no non-core dependencies (on Perl 5.14+. There are
a couple of non-core dependencies on older versions of Perl.)

Attribute C<isa> options are Type::Tiny type constraints expressed as
strings. Mite looks them up during compilation using C<dwim_type>
from L<Type::Utils>, and pre-loads L<Types::Standard>,
L<Types::Common::String>, and L<Types::Common::Numeric> for you.

The C<signature_for> keyword is similar to the corresponding function
in L<Type::Params>. Again, note that types are expressed as strings
and looked up using C<dwim_type>.

Any types which are inlineable should work. If using coercion, any
coercions which are inlineable should work.

=head2 Custom Types in Mite

You can define your own type library (say, Your::Project::Types) using
L<Type::Library> as normal:

   package Your::Project::Types;
   
   use Type::Library
      -extends => [ 'Types::Standard', 'Types::Common::Numeric' ];
   
   __PACKAGE__->add_type(
      name    => 'Widget',
      parent  => InstanceOf['Your::Project::Widget'],
   )->coercion->add_type_coercions(
      HashRef, q{Your::Project::Widget->new($_)},
   );
   
   __PACKAGE__->make_immutable;
   
   1;

Now if your classes load Your::Project::Types they'll suddenly have a
dependency on Type::Library, so you don't get that nice zero-dependency
feeling. But you can add this to your C<< .mite/config >> file:

   types: Your::Project::Types

Now Mite will know to load that type library at compile time, and will
make those types available as stringy types everywhere.

=head2 Compiled Type Libraries

It does look really pretty to not have to quote your type constraints:

   has name => (
      is   => ro,
      isa  => Str,
   );

One solution for that is L<Type::Library::Compiler>.

Say you've created the custom type library above, you can use 
L<Type::Library::Compiler> to compile it into a module called
Your::Project::Types::Compiled, which just uses L<Exporter> and
doesn't rely on L<Type::Library> or any other part of L<Type::Tiny>.

Then your Widget class can use that:

   package Your::Project::Widget;
   
   use Your::Project::Mite -all;
   use Your::Project::Types::Compiled -types;
   
   has name => (
      is   => ro,
      isa  => Str,
   );
   
   has id => (
      is   => ro,
      isa  => PositiveInt,
   );
   
   signature_for warble => (
      named => [
         foo   => Int,
         bar   => ArrayRef,
      ],
   );
   
   sub warble {
      my ( $self, $arg ) = @_;
      printf( "%s: %d\n", $self->name, $arg->foo );
      return;
   }
   
   1;

The compiled type libraries are more limited than real type libraries.
You can't, for example, do parameterized types with them. However, they
still offer some cool features like:

   Foo->check( $value )     # a few basic methods like this
   is_Foo( $value )         # boolean checks
   assert_Foo( $value )     # assertions which die
   Foo | Bar                # unions!

This way you can write a project with object orientation, roles, method
modifiers, type-checked attributes, type-checked signatures, and even
coercion, with no non-core dependencies! (The tools like L<Mite> and
L<Type::Library::Compiler> are only needed by the developer, not the
end user.)

=head1 NEXT STEPS

Here's your next step:

=over

=item * L<Type::Tiny::Manual::UsingWithClassTiny>

Including how to Type::Tiny in your object's C<BUILD> method, and
third-party shims between Type::Tiny and Class::Tiny.

=back

=head1 AUTHOR

Toby Inkster E<lt>tobyink@cpan.orgE<gt>.

=head1 COPYRIGHT AND LICENCE

This software is copyright (c) 2022-2023 by Toby Inkster.

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

=head1 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.

=cut