/;
33 | s/<\/body>/<\/div><\/body>/;
34 | });
35 | }
36 | }
37 |
--------------------------------------------------------------------------------
/build/tools/build_pdf.pl:
--------------------------------------------------------------------------------
1 | #!/usr/bin/perl
2 |
3 | use strict;
4 | use warnings;
5 |
6 | use File::Spec::Functions qw( catfile catdir splitpath );
7 |
8 | # getting chapter list
9 | my @chapters = get_chapter_list();
10 |
11 | # Check if pod2pdf is available
12 | require App::pod2pdf
13 | or die "pod2pdf is not present in your PATH; please install App::pod2pdf\n";
14 |
15 | my $outpath = catdir( qw( build pdf ) );
16 |
17 | for my $chapter ( @chapters ){
18 | my @filename = split( /\./ , $chapter );
19 | print "Converting $chapter to pdf\n";
20 | system( 'pod2pdf', '--noheader', $chapter, '--output-file',
21 | catfile(qw( build pdf ), (splitpath($filename[0]))[-1] . '.pdf' ) );
22 | }
23 |
24 | print "PDFs have been generated in build/pdf\n";
25 |
26 | sub get_chapter_list
27 | {
28 | my $glob_path = catfile( qw( build chapters chapter_??.pod ) );
29 | return glob $glob_path;
30 | }
31 |
--------------------------------------------------------------------------------
/build/tools/open_browser.pl:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env perl
2 |
3 | use Modern::Perl '2019';
4 | use Browser::Open;
5 | use Path::Tiny;
6 | use feature 'signatures';
7 | no warnings 'experimental::signatures';
8 |
9 | exit main( @ARGV );
10 |
11 | sub main($chapter = undef) {
12 | return Browser::Open::open_browser('file://' . get_chapter($chapter), 1 );
13 | }
14 |
15 | sub get_chapter($chapter_number) {
16 | return get_file(shift)->absolute;
17 | }
18 |
19 | sub get_file($chapter_number) {
20 | my $index = path('build/html/index.html');
21 | return $index unless $chapter_number;
22 | return $index unless $chapter_number =~ /\A\d+\Z/;
23 |
24 | for my $num ($chapter_number, '0' . $chapter_number) {
25 | my $chapter_path = path('build/html/chapter_' . $num . '.html');
26 | return $chapter_path if $chapter_path->exists;
27 | }
28 |
29 | return $index;
30 | }
31 |
--------------------------------------------------------------------------------
/build/xhtml/.gitignore:
--------------------------------------------------------------------------------
1 | *
2 |
--------------------------------------------------------------------------------
/images/mp_cover_full.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chromatic/modern_perl_book/bb03cb0404422853060b8493f7992cf39343e658/images/mp_cover_full.png
--------------------------------------------------------------------------------
/images/mp_cover_med.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chromatic/modern_perl_book/bb03cb0404422853060b8493f7992cf39343e658/images/mp_cover_med.png
--------------------------------------------------------------------------------
/images/mp_cover_thumb.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/chromatic/modern_perl_book/bb03cb0404422853060b8493f7992cf39343e658/images/mp_cover_thumb.png
--------------------------------------------------------------------------------
/sections/advanced_oo.pod:
--------------------------------------------------------------------------------
1 | =head1 Advanced OO Perl
2 |
3 | Z
4 |
5 | Creating and using objects in Perl with Moose (L) is easy. I
6 | good programs is not. It's as easy to overdesign a program as it is to
7 | underdesign it. Only practical experience can help you understand the most
8 | important design techniques, but several principles can guide you.
9 |
10 | =head2 Favor Composition Over Inheritance
11 |
12 | X
13 | X
14 |
15 | Novice OO designs often overuse inheritance to reuse code and to exploit
16 | polymorphism. The result is a deep class hierarchy with responsibilities
17 | scattered all over the place. Maintaining this code is difficult--who knows
18 | where to add or edit behavior? What happens when code in one place conflicts
19 | with code declared elsewhere?
20 |
21 | X
22 | X
23 |
24 | Inheritance is only one of many tools for OO programmers. It's not always the
25 | right tool. It's often the wrong tool. A C may extend C
26 | (an I), but C may better I several C
27 | objects as instance attributes (a I).
28 |
29 | Decomposing complex classes into smaller, focused entities improves
30 | encapsulation and reduces the possibility that any one class or role does too
31 | much. Smaller, simpler, and better encapsulated entities are easier to
32 | understand, test, and maintain.
33 |
34 | =head2 Single Responsibility Principle
35 |
36 | X
37 |
38 | When you design your object system, consider the responsibilities of each
39 | entity. For example, an C object may represent specific information
40 | about a person's name, contact information, and other personal data, while a
41 | C object may represent business responsibilities. Separating these
42 | entities in terms of their responsibilities allows the C class to
43 | consider only the problem of managing information specific to who the person is
44 | and the C class to represent what the person does. (Two Cs may
45 | have a C-sharing arrangement, for example, or one C may have the
46 | CFO and the COO Cs.)
47 |
48 | When each class has a single responsibility, you reduce coupling between
49 | classes and improve the encapsulation of class-specific data and behavior.
50 |
51 | =head2 Don't Repeat Yourself
52 |
53 | X
54 |
55 | Complexity and duplication complicate development and maintenance. The I
56 | principle (Don't Repeat Yourself) is a reminder to seek out and to eliminate
57 | duplication within the system. Duplication exists in data as well as in code.
58 | Instead of repeating configuration information, user data, and other important
59 | artifacts of your system, create a single, canonical representation of that
60 | information from which you can generate the other artifacts.
61 |
62 | This principle helps you to find the optimal representation of your system and
63 | its data and reduces the possibility that duplicate information will get out of
64 | sync.
65 |
66 | =head2 Liskov Substitution Principle
67 |
68 | X
69 |
70 | The Liskov substitution principle suggests that you should be able to
71 | substitute a specialization of a class or a role for the original without
72 | violating the original's API. In other words, an object should be as or more
73 | general with regard to what it expects and at least as specific about what it
74 | produces as the object it replaces.
75 |
76 | Imagine two classes, C and its child class C. If the classes
77 | follow the Liskov substitution principle, you can replace every use of
78 | C objects with C objects in the test suite, and everything
79 | should pass. See Reg Braithwaite's
80 | "IS-STRICTLY-EQUIVALENT-TO-A"N.>
81 | for more details.
82 |
83 | =head2 Subtypes and Coercions
84 |
85 | Z
86 |
87 | X
88 | X
89 | X
90 |
91 | Moose allows you to declare and use types and extend them through subtypes to
92 | form ever more specialized descriptions of what your data represents and how it
93 | behaves. These type annotations help verify that the function and method
94 | parameters are correct--or can be coerced into the proper data types.
95 |
96 | X>
97 | X>
98 |
99 | For example, you may wish to allow people to provide dates to a C entry
100 | as strings while representing them as C instances internally. You can
101 | do this by creating a Date type and adding a coercion from string types. See
102 | C and C for more information.
103 |
104 | =head2 Immutability
105 |
106 | Z
107 |
108 | X
109 |
110 | With a well-designed object, you tell it I, not I.
111 | If you find yourself accessing object instance data (even through accessor
112 | methods) outside of the object itself, you may have too much access to an
113 | object's internals.
114 |
115 | OO novices often treat objects as if they were bundles of records which use
116 | methods to get and set internal values. This simple technique leads to the
117 | unfortunate temptation to spread the object's responsibilities throughout the
118 | entire system.
119 |
120 | You can prevent inappropriate access by making your objects immutable. Provide
121 | the necessary data to their constructors, then disallow any modifications of
122 | this information from outside the class. Expose no methods to mutate instance
123 | data--make all of your public accessors read-only and use internal attribute
124 | writers sparingly. Once you've constructed such an object, you know it's always
125 | in a valid state. You can never modify its data to put it in an invalid state.
126 |
127 | This takes tremendous discipline, but the resulting systems are robust,
128 | testable, and maintainable. Some designs go as far as to prohibit the
129 | modification of instance data I the class itself.
130 |
--------------------------------------------------------------------------------
/sections/anonymous_functions.pod:
--------------------------------------------------------------------------------
1 | =head1 Anonymous Functions
2 |
3 | Z
4 |
5 | X
6 |
7 | An I is a function without a name. It behaves exactly like
8 | a named function--you can invoke it, pass it arguments, return values from it,
9 | and take references to it. Yet you can only access an anonymous function by
10 | reference (L), not by name.
11 |
12 | X
13 | X
14 | X
15 |
16 | A Perl idiom known as a I uses hashes to associate input with
17 | behavior:
18 |
19 | =begin programlisting
20 |
21 | my %dispatch = (
22 | plus => \&add_two_numbers,
23 | minus => \&subtract_two_numbers,
24 | times => \&multiply_two_numbers,
25 | );
26 |
27 | sub add_two_numbers { $_[0] + $_[1] }
28 | sub subtract_two_numbers { $_[0] - $_[1] }
29 | sub multiply_two_numbers { $_[0] * $_[1] }
30 |
31 | sub dispatch {
32 | my ($left, $op, $right) = @_;
33 |
34 | return unless exists $dispatch{ $op };
35 |
36 | return $dispatch{ $op }->( $left, $right );
37 | }
38 |
39 | =end programlisting
40 |
41 | The C function takes arguments of the form C<(2, 'times', 2)>,
42 | evaluates the operation, and returns the result. A trivial calculator
43 | application could use C to figure out which calculation to perform
44 | based on user input.
45 |
46 | =head2 Declaring Anonymous Functions
47 |
48 | X>
49 |
50 | The C builtin used without a name creates and returns an anonymous
51 | function. Use this function reference where you'd use a reference to a named
52 | function, such as to declare the dispatch table's functions in place:
53 |
54 | =begin programlisting
55 |
56 | my %dispatch = (
57 | plus => sub { $_[0] + $_[1] },
58 | minus => sub { $_[0] - $_[1] },
59 | times => sub { $_[0] * $_[1] },
60 | dividedby => sub { $_[0] / $_[1] },
61 | raisedto => sub { $_[0] ** $_[1] },
62 | );
63 |
64 | =end programlisting
65 |
66 | =begin tip Defensive Dispatch
67 |
68 | Only those functions within this dispatch table are available for users to
69 | call. If your dispatch function used a user-provided string as the literal name
70 | of functions, a malicious user could call any function anywhere by passing a
71 | fully-qualified name such as C<'Internal::Functions::malicious_function'>.
72 |
73 | =end tip
74 |
75 | You may also see anonymous functions passed as function arguments:
76 |
77 | =begin programlisting
78 |
79 | sub invoke_anon_function {
80 | my $func = shift;
81 | return $func->( @_ );
82 | }
83 |
84 | sub named_func {
85 | say 'I am a named function!';
86 | }
87 |
88 | invoke_anon_function( \&named_func );
89 | invoke_anon_function( B );
90 |
91 | =end programlisting
92 |
93 | =head2 Anonymous Function Names
94 |
95 | X
96 | X>
97 |
98 | Use introspection to determine whether a function is named or anonymous,
99 | whether through C or the CPAN module C's C
100 | function:
101 |
102 | =begin programlisting
103 |
104 | package ShowCaller;
105 |
106 | sub show_caller {
107 | my ($package, $file, $line, $sub) = caller(1);
108 | say "Called from $sub in $package:$file:$line";
109 | }
110 |
111 | sub main {
112 | my $anon_sub = sub { show_caller() };
113 | show_caller();
114 | $anon_sub->();
115 | }
116 |
117 | main();
118 |
119 | =end programlisting
120 |
121 | The result may be surprising:
122 |
123 | =begin screen
124 |
125 | Called from ShowCaller::B
126 | in ShowCaller:anoncaller.pl:20
127 | Called from ShowCaller::B<__ANON__>
128 | in ShowCaller:anoncaller.pl:17
129 |
130 | =end screen
131 |
132 | X>
133 |
134 | The C<__ANON__> in the second line of output demonstrates that the anonymous
135 | function has no name that Perl can identify. The CPAN module C's
136 | C function allows you to attach names to anonymous functions:
137 |
138 | =begin programlisting
139 |
140 | use Sub::Name;
141 | use Sub::Identify 'sub_name';
142 |
143 | my $anon = sub {};
144 | say sub_name( $anon );
145 |
146 | my $named = subname( 'pseudo-anonymous', $anon );
147 | say sub_name( $named );
148 | say sub_name( $anon );
149 |
150 | say sub_name( sub {} );
151 |
152 | =end programlisting
153 |
154 | This program produces:
155 |
156 | =begin screen
157 |
158 | __ANON__
159 | pseudo-anonymous
160 | pseudo-anonymous
161 | __ANON__
162 |
163 | =end screen
164 |
165 | Be aware that both references refer to the same underlying anonymous function.
166 | Using C on one reference will change that underlying function; all
167 | other references to that function will see the new name.
168 |
169 | =head2 Implicit Anonymous Functions
170 |
171 | X
172 |
173 | X>
174 |
175 | Perl allows you to declare anonymous functions as function arguments without
176 | using the C keyword. Though this feature exists nominally to enable
177 | programmers to write their own syntax such as that for C