Move some stuff from PLANS to TODO, and remove PLANS
[gitmo/Moose.git] / TODO
1 == Todo for 2.0200
2
3 === Revise MetaRole API to reunify class/role metaroles:
4
5   apply_metaroles(
6       for   => $meta,
7       roles => {
8           attribute => [...],
9           class     => [...],
10           role_attribute => [ ... ],
11       }
12   );
13
14 If the $meta is a class, we apply the roles to the class. If it's a role, we
15 hold onto them and apply them as part of applying the role to a class.
16
17 To make this all work nicely, we'll probably want to track the original role
18 where a method was defined, just like we do with attributes currently. We'll
19 also need to store method modifiers with their original role, which may mean
20 adding some sort of Moose::Meta::Role::MethodModifier class.
21
22 For each role-specific thing (methods, attributes, etc.) we should allow a
23 role_attribute, role_method, etc. key. The common case will be that the
24 metaroles are intended for the consuming class, but we should allow for
25 metaroles on the role's metaobjects as well.
26
27 === Remove a bunch of deprecated crap
28
29 See Moose::Manual::Delta for a list. Some of this is important to make merging
30 Class::MOP into Moose core much easier. Other is just removing complexity
31 needed to support ancient APIs.
32
33 == Old todo (does anyone look at this?)
34
35 -------------------------------------------------------------------------------
36 BUGS
37 -------------------------------------------------------------------------------
38
39 -------------------------------------------------------------------------------
40 FEATURES
41 -------------------------------------------------------------------------------
42
43 - DDuncan's Str types
44
45 subtype 'Str'
46     => as 'Value'
47     => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
48     => optimize_as { defined($_[0]) && !ref($_[0]) };
49
50 subtype 'Blob'
51     => as 'Value'
52     => where { !Encode::is_utf8( $_[0] ) }
53     => optimize_as { defined($_[0]) && !ref($_[0]) };
54
55 - type unions
56
57 Add support for doing it with Classes which do not have
58 a type constraint yet created
59
60 - type intersections
61
62 Mostly just for Roles
63
64 - inherited slot specs
65
66 'does' can be added to,.. but not changed
67 (need type unions for this)
68
69 - proxy attributes
70
71 a proxied attribute is an attribute
72 which looks like an attribute,
73 talks like an attribute, smells
74 like an attribute,.. but if you
75 look behind the curtain,.. its
76 over there.. in that other object
77
78 (... probably be a custom metaclass)
79
80 - local coerce
81
82 [13:16]         mst     stevan: slight problem with coerce
83 [13:16]         mst     I only get to declare it once
84 [13:17]         mst     so if I'm trying to declare it cast-style per-source-class rather than per-target-class
85 [13:17]         mst     I am extremely screwed
86 [13:17]         stevan  yes
87 [13:17]         stevan  they are not class specific
88 [13:18]         stevan  they are attached to the type constraint itself
89 [13:18]         *       stevan ponders anon-coercion-metaobjects
90 [13:18]         mst     yes, that's fine
91 [13:19]         mst     but when I declare a class
92 [13:19]         mst     I want to be able to say "this class coerces to X type via <this>"
93 [13:19]         stevan  yeah something like that
94 [13:19]         stevan  oh,.. hmm
95 [13:20]         stevan  sort of like inflate/deflate?
96 [13:20]         stevan  around the accessors?
97 [13:25]         *       bluefeet has quit (Remote host closed the connection)
98 [13:27]         mst     no
99 [13:27]         mst     nothing like that
100 [13:27]         mst     like a cast
101 [13:31]         mst     stevan: $obj->foo($bar); where 'foo' expects a 'Foo' object
102 [13:31]         mst     stevan: is effectively <Foo>$bar, right?
103 [13:32]         mst     stevan: I want to be able to say in package Bar
104 [13:32]         mst     stevan: coerce_to 'Foo' via { ... };
105 [13:32]         mst     etc.
106 [13:53]         stevan  hmm
107
108 -----------------------------------------------------------
109 -- Type Constraints refactor
110 -----------------------------------------------------------
111
112 - add support for locally scoped TC
113
114 This would borrow from MooseX::TypeLibrary to prefix the TC with the name
115 of the package. It would then be accesible from the outside as the fully
116 scoped name, but the local attributes would use it first. (this would need support
117 in the registry for this).
118
119 - look into sugar extensions
120
121 Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This
122 would allow custom metaclasses to provide roles to extend the sugar syntax with.
123
124 (NOTE: Talk to phaylon a bit more on this)
125
126 - allow a switch of some kind to optionally turn TC checking off at runtime
127
128 The type checks can get expensive and some people have suggested that allowing
129 the checks to be turned off would be helpful for deploying into performance
130 intensive systems. Perhaps this can actually be done as an option to make_immutable?
131
132 - misc. minor bits
133
134 * make the errors for TCs use ->message
135 * look into localizing the messages too
136 * make ANON TCs be lazy, so they can possibly be subsituted for the real thing later
137 * make ANON TCs more introspectable
138 * add this ...
139
140 #
141 #   Type Definition
142 #
143 subtype 'Username',
144    from 'Str',
145   where {     (/[a-z][a-z0-9]+/i or fail('Invalid character(s)'))
146           and (length($_) >= 5   or fail('Too short (less than 5 chars)'))
147         }
148 on_fail { MyException->throw(value => $_[0], message => $_[1]) };
149
150 # fail() will just return false unless the call is made via
151 $tc->check_or_fail($value);
152
153 * and then something like this:
154
155 subtype Foo => as Bar => where { ... } => scoped => -global;
156 subtype Foo => as Bar => where { ... } => scoped => -local;
157
158 # or
159
160 subtype Foo => as Bar => where { ... } => in __PACKAGE__ ;
161
162 # or (not sure if it would be possible)
163
164 my $Foo = subtype Bar => where { ... };
165
166 # ----------
167
168 [17:10]  <autarch> stevan: it should do it if I pass coerce => 1 as part of the attribute definition
169 [17:12]  <stevan> autarch: what I am not 100% sure of is how to tell it to deep coerce and when to not
170 [17:13]  <stevan> cause a basic coerce is from A to B
171 [17:13]  <autarch> hmm
172 [17:13]  <stevan> which is valid for collection types too
173 [17:13]  <stevan> deep coercion is what you are asking for
174 [17:13]  <autarch> yeah
175 [17:13]  <stevan> so perhaps we add deep_coerce => 1
176 [17:13]  <stevan> which will do it
177 [17:13]  <autarch> that's fine for me
178 [17:13]  <stevan> k
179
180 coerce_deeply => 1 # reads better
181
182 -------------------------------------------------------------------------------
183 INTERNALS
184 -------------------------------------------------------------------------------
185
186 - rationalize all the get_X methods for classes (and roles)
187
188 We have get_attribute, get_attributes_list, get_all_attributes,
189 etc. First, we need to make the method names consistent. If something
190 returns an attribute vs a name, that needs to be clear from the method
191 name. We also need to make sure that local vs. "entire inheritance
192 chain" is clear from the name.
193
194 This is mostly a CMOP change.
195
196 - Metaclass constructors
197
198 There's a _lot_ of different conventions in here. Some things to consider:
199
200 * new vs _new
201 * allowing new( 'name', %args ) vs ( name => 'name', %args )
202 * Method->wrap vs Method->new
203
204 - Moose::Meta::TypeConstraint::Parameter{izable,ized}
205
206 The relationship between these two classes is very odd. In particular,
207 this line in Parameterized is insane:
208
209     foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
210
211 Why does it need to loop through all parameterizable types? Shouldn't
212 it know which parameterizable type it "came from"?
213
214 - Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
215
216 The Util module has _way_ too much functionality. It needs to be
217 refactored so it's a thin sugar layer on top of the meta API. As it
218 stands now, it does things like parse type names (and determine if
219 they're valid), manage the registry, and much more.
220
221 - Anything with a _(meta)?class method
222
223 Every method that returns a class name needs to become a rw attribute
224 that can be set via the constructor.
225
226 - The Moose::Error stuff
227
228 This is sort of half-implemented. We still use Carp directly, and the
229 internals can't decide how to throw an error (is it
230 Moose->throw_error, __PACKAGE__->throw_error, what?).
231
232 The internals need to be made consistent before we expose this to the
233 rest of the world.
234
235 -------------------------------------------------------------------------------
236 TO PONDER
237 -------------------------------------------------------------------------------
238
239 - Moose "strict" mode
240
241 use Moose 'strict'; This would allow us to have all sort of expensive tests
242 which can be turned off in prod.
243
244 - Moose::Philosophy.pod
245
246 To explain Moose from a very high level
247
248 - moosedoc
249
250 We certainly have enough meta-information to make pretty complete POD docs.
251
252
253