TODO

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