3 === Revise MetaRole API to reunify class/role metaroles:
10 role_attribute => [ ... ],
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.
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.
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.
27 === Remove a bunch of deprecated crap
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.
33 == Old todo (does anyone look at this?)
35 -------------------------------------------------------------------------------
37 -------------------------------------------------------------------------------
39 -------------------------------------------------------------------------------
41 -------------------------------------------------------------------------------
47 => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
48 => optimize_as { defined($_[0]) && !ref($_[0]) };
52 => where { !Encode::is_utf8( $_[0] ) }
53 => optimize_as { defined($_[0]) && !ref($_[0]) };
57 Add support for doing it with Classes which do not have
58 a type constraint yet created
64 - inherited slot specs
66 'does' can be added to,.. but not changed
67 (need type unions for this)
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
78 (... probably be a custom metaclass)
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
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)
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 { ... };
108 -------------------------------------------------------------------------------
110 -------------------------------------------------------------------------------
112 - rationalize all the get_X methods for classes (and roles)
114 We have get_attribute, get_attributes_list, get_all_attributes,
115 etc. First, we need to make the method names consistent. If something
116 returns an attribute vs a name, that needs to be clear from the method
117 name. We also need to make sure that local vs. "entire inheritance
118 chain" is clear from the name.
120 This is mostly a CMOP change.
122 - Metaclass constructors
124 There's a _lot_ of different conventions in here. Some things to consider:
127 * allowing new( 'name', %args ) vs ( name => 'name', %args )
128 * Method->wrap vs Method->new
130 - Moose::Meta::TypeConstraint::Parameter{izable,ized}
132 The relationship between these two classes is very odd. In particular,
133 this line in Parameterized is insane:
135 foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
137 Why does it need to loop through all parameterizable types? Shouldn't
138 it know which parameterizable type it "came from"?
140 - Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
142 The Util module has _way_ too much functionality. It needs to be
143 refactored so it's a thin sugar layer on top of the meta API. As it
144 stands now, it does things like parse type names (and determine if
145 they're valid), manage the registry, and much more.
147 - Anything with a _(meta)?class method
149 Every method that returns a class name needs to become a rw attribute
150 that can be set via the constructor.
152 - The Moose::Error stuff
154 This is sort of half-implemented. We still use Carp directly, and the
155 internals can't decide how to throw an error (is it
156 Moose->throw_error, __PACKAGE__->throw_error, what?).
158 The internals need to be made consistent before we expose this to the
161 -------------------------------------------------------------------------------
163 -------------------------------------------------------------------------------
165 - Moose "strict" mode
167 use Moose 'strict'; This would allow us to have all sort of expensive tests
168 which can be turned off in prod.
170 - Moose::Philosophy.pod
172 To explain Moose from a very high level
176 We certainly have enough meta-information to make pretty complete POD docs.