From: Jesse Luehrs <doy@tozt.net>
Date: Fri, 16 Sep 2011 20:00:51 +0000 (-0500)
Subject: push some todo stuff back to 2.06
X-Git-Tag: 2.0300~68
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=b927b1d4a771a582803f761a77c0686916d330d3;p=gitmo%2FMoose.git

push some todo stuff back to 2.06
---

diff --git a/TODO b/TODO
index c6a1767..498c126 100644
--- a/TODO
+++ b/TODO
@@ -14,6 +14,23 @@ good), although it's hard to test to see what actually works.
 RT#69839 - UNIVERSAL methods should show up as methods, so things like method
 modifiers work
 
+=== Deprecate old-style Moose extensions
+
+Moose extensions that work by calling Moose->init_meta(metaclass =>
+'Some::Custom::Metaclass', ...) during their own init_meta should be
+deprecated, so they can be removed later (this should fix the issues with
+init_meta generation in Moose::Exporter, see RT51561)
+
+=== Register implicitly created class/role types
+
+When you do has foo => (isa => 'Bar'), it returns a class_type for Bar, but
+doesn't register it. This means that later you can declare "subtype 'Bar', as
+'Str', ..." and it'll work, and later instances of the 'Bar' type will use that
+one. We should register the implicitly created ones so that trying to redefine
+it after it's used throws an error.
+
+== Todo for 2.0600
+
 === Revise MetaRole API to reunify class/role metaroles:
 
   apply_metaroles(
@@ -38,21 +55,6 @@ role_attribute, role_method, etc. key. The common case will be that the
 metaroles are intended for the consuming class, but we should allow for
 metaroles on the role's metaobjects as well.
 
-=== Deprecate old-style Moose extensions
-
-Moose extensions that work by calling Moose->init_meta(metaclass =>
-'Some::Custom::Metaclass', ...) during their own init_meta should be
-deprecated, so they can be removed later (this should fix the issues with
-init_meta generation in Moose::Exporter, see RT51561)
-
-=== Register implicitly created class/role types
-
-When you do has foo => (isa => 'Bar'), it returns a class_type for Bar, but
-doesn't register it. This means that later you can declare "subtype 'Bar', as
-'Str', ..." and it'll work, and later instances of the 'Bar' type will use that
-one. We should register the implicitly created ones so that trying to redefine
-it after it's used throws an error.
-
 === Attributes in roles need to be able to participate in role composition
 
 Right now, this fails with no decent workaround: