Commit | Line | Data |
7e2ec16e |
1 | =head1 Upgrading to Catalyst 5.80 |
2 | |
3 | Work in progress |
4 | |
5 | =head1 Known backwards compatibility breakages. |
6 | |
7 | =head2 Catalyst::Plugin::Authentication |
8 | |
9 | You need at least version FIXME of Catalyst::Plugin::Authentication. |
10 | |
11 | =head2 Moose applications |
12 | |
845bfcd2 |
13 | Moose components for Catalyst 5.70 needed to do |
7e2ec16e |
14 | |
845bfcd2 |
15 | extends qw/Moose::Object Catalyst::Component/; |
7e2ec16e |
16 | |
845bfcd2 |
17 | to be able to use the constructor provided by Moose. In 5.80 |
18 | C<Catalyst::Component> already inherits from C<Moose::Object>. Therefor you |
19 | shouldn't directly inherit from C<Moose::Object> yourself, otherwise your |
20 | Class' @ISA will not linearise with C3. |
7e2ec16e |
21 | |
04a48104 |
22 | =head2 Anonymous closures installed directly into the symbol table |
23 | |
24 | If you have any code which installs anonymous subroutine references directly |
25 | into the symbol table, you may encounter breakages. The simplest solution is |
26 | to use L<Sub::Name> to name the subroutine. Example: |
27 | |
28 | #Originalcode, likely to break: |
29 | my $full_method_name = join('::',$package_name, $method_name); |
30 | *$full_method_name = sub { ... }; |
31 | |
32 | #Fixed Code |
33 | use Sub::Name 'subname'; |
34 | my $full_method_name = join('::',$package_name, $method_name); |
35 | *$full_method_name = subname $full_method_name, sub { ... }; |
36 | |
37 | Additionally, you can take advantage of Catalyst's use of L<Class::MOP> and |
38 | install the closure using the appropriate metaclass. Example: |
39 | |
40 | use Class::MOP; |
41 | my $metaclass = Moose::Meta::Class->initialize($package_name); |
42 | $metaclass->add_method($method_name => sub { ... }); |
43 | |
7e2ec16e |
44 | =head2 Components without new methods |
45 | |
46 | FIXME |
47 | |
48 | =head2 Components without COMPONENT methods |
49 | |
50 | FIXME |
51 | |
52 | =head2 __PACKAGE__->mk_accessor('meta'); |
53 | |
54 | Won't work due to a limitation of L<MooseX::Emulate::Class::Accessor::Fast> |
55 | |
56 | FIXME |
57 | |
58 | =head2 Class::Data::Inheritable side effects |
59 | |
60 | FIXME |
61 | |
62 | =head2 Extending Catalyst::Request or other classes in an ad-hoc manor using mk_accessor |
63 | |
64 | FIXME |
65 | |
66 | =head2 require $class was successful but the package is not defined. |
67 | |
68 | FIXME Warning |
69 | |
8be895a7 |
70 | =head2 $c->plugin method |
71 | |
72 | Deprecated |
73 | |
7e2ec16e |
74 | =head2 Components which inherit Catalyst::Component's COMPONENT method, who's new method does not return a true value. |
75 | |
76 | Previously if your new method returned a false value, then your class' configuration would be blessed into a hash on your behalf, |
77 | and this would be returned from the COMPONENT method. This is no longer supported. You are not recommended to implement your own new method |
78 | in components, instead, you should inherit the new method from Catalyst::Component, and use Moose's BUILD functionality |
79 | to perform any construction work necessary for your sub-class. |
80 | |
81 | |
c571d2c8 |
82 | =head1 WARNINGS |
83 | |
84 | =head2 Methods in Catalyst::Dispatcher |
85 | |
86 | The following methods in Catalyst::Dispatcher are likely to change |
87 | significantly in the 5.8X release series, and therefore their use is highly |
88 | deprecated. |
89 | |
90 | =over |
91 | |
92 | =item tree |
93 | |
94 | =item dispatch_types |
95 | |
96 | =item registered_dispatch_types |
97 | |
98 | =item method_action_class |
99 | |
100 | =item action_hash |
101 | |
102 | =item container_hash |
103 | |
104 | =back |
105 | |
106 | The first time one of these methods is called, a warning will be emitted: |
7e2ec16e |
107 | |
108 | Class $class is calling the deprecated method Catalyst::Dispatcher::$public_method_name,\n" |
109 | . "this will be removed in Catalyst 5.9X" |
110 | |
c571d2c8 |
111 | You should B<NEVER> be calling any of these methods from application code. |
112 | |
113 | Plugins authors and maintainers whos plugins need to call these methods |
114 | should email the development list to discuss your use-case, and what a |
115 | better API should look like. |
7e2ec16e |
116 | |
117 | =head2 Confused multiple inheritence with Catalyst::Component::COMPONENT |
118 | |
119 | Warning message: |
120 | |
121 | There is a COMPONENT method resolving after Catalyst::Component |
122 | in ${next_package}. |
123 | |
124 | This means that one of the packages on the right hand side of |
125 | Catalyst::Component in your Class' inheritance hierarchy defines |
126 | a COMPONENT method. |
127 | |
128 | Previously, Catalyst's COMPONENT method would delegate to the |
129 | method on the right hand side, which could then delegate back again |
130 | with NEXT. This (as it is insane), is no longer supported, as it |
131 | makes no sense with C3 method dispatch order. |
132 | |
133 | Therefore the correct fix is to re-arrange your class' inheritance |
134 | hierarchy so that the COMPONENT method you would like to inherit is |
135 | the first COMPONENT method in your @ISA. |
136 | |
137 | |
138 | =cut |