-------------------------------------------------------------------------------
-TODO
+BUGS
-------------------------------------------------------------------------------
-- make way to iterate over all Moose classes
+-------------------------------------------------------------------------------
+FEATURES
+-------------------------------------------------------------------------------
-- roles
+- DDuncan's Str types
-Need to figure out the details of composite roles
+subtype 'Str'
+ => as 'Value'
+ => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
+ => optimize_as { defined($_[0]) && !ref($_[0]) };
+
+subtype 'Blob'
+ => as 'Value'
+ => where { !Encode::is_utf8( $_[0] ) }
+ => optimize_as { defined($_[0]) && !ref($_[0]) };
- type unions
-Add support for doing it with Classes which do not have
+Add support for doing it with Classes which do not have
a type constraint yet created
- type intersections
- inherited slot specs
-[10:49] stevan does can be added to,.. but not changed
+'does' can be added to,.. but not changed
+(need type unions for this)
-- triggers
+- proxy attributes
-[18:18] mst what I'd really like is just to say trigger => 'some_method'
+a proxied attribute is an attribute
+which looks like an attribute,
+talks like an attribute, smells
+like an attribute,.. but if you
+look behind the curtain,.. its
+over there.. in that other object
+
+(... probably be a custom metaclass)
+
+- local coerce
+
+[13:16] mst stevan: slight problem with coerce
+[13:16] mst I only get to declare it once
+[13:17] mst so if I'm trying to declare it cast-style per-source-class rather than per-target-class
+[13:17] mst I am extremely screwed
+[13:17] stevan yes
+[13:17] stevan they are not class specific
+[13:18] stevan they are attached to the type constraint itself
+[13:18] * stevan ponders anon-coercion-metaobjects
+[13:18] mst yes, that's fine
+[13:19] mst but when I declare a class
+[13:19] mst I want to be able to say "this class coerces to X type via <this>"
+[13:19] stevan yeah something like that
+[13:19] stevan oh,.. hmm
+[13:20] stevan sort of like inflate/deflate?
+[13:20] stevan around the accessors?
+[13:25] * bluefeet has quit (Remote host closed the connection)
+[13:27] mst no
+[13:27] mst nothing like that
+[13:27] mst like a cast
+[13:31] mst stevan: $obj->foo($bar); where 'foo' expects a 'Foo' object
+[13:31] mst stevan: is effectively <Foo>$bar, right?
+[13:32] mst stevan: I want to be able to say in package Bar
+[13:32] mst stevan: coerce_to 'Foo' via { ... };
+[13:32] mst etc.
+[13:53] stevan hmm
-- attribute delgates
+-------------------------------------------------------------------------------
+INTERNALS
+-------------------------------------------------------------------------------
-Introduce capability to control the generated wrapper. Useful for when you have
-a wrapper that should implement the interface of it's child, but decorate with
-more metadata.
+- rationalize all the get_X methods for classes (and roles)
-- proxy attributes
+We have get_attribute, get_attributes_list, get_all_attributes,
+etc. First, we need to make the method names consistent. If something
+returns an attribute vs a name, that needs to be clear from the method
+name. We also need to make sure that local vs. "entire inheritance
+chain" is clear from the name.
+
+Finally, kill all the public get_X_map methods. The hashref it returns
+is the internal reference, and the fact that it _is_ a hashref is just
+an implementation detail.
+
+This is mostly a CMOP change.
+
+- Metaclass constructors
+
+There's a _lot_ of different conventions in here. Some things to consider:
+
+* new vs _new
+* allowing new( 'name', %args ) vs ( name => 'name', %args )
+* Method->wrap vs Method->new
+
+- Role & Class
-[15:49] stevan you want a proxied attribute
-[15:49] stevan which looks like an attribute,
- talks like an attribute, smells
- like an attribute,.. but if you
- look behind the curtain,.. its
- over there.. in that other object
+These two share a _lot_ of logic, but it's not via shared code. Maybe
+implement some sort of role-lit internal thing so we can have a
+"HasAttributes" and "HasMethods" role for classes and roles.
-- compile time extends
+- Moose::Meta::TypeConstraint::Parameter{izable,ized}
-[00:39] sri but maybe a better syntax for compile time extends
-[00:39] stevan I have been pondering that actually
-[00:39] sri use Moose extends => Foo::Bar
-[00:40] stevan I think now that we have the Sub::Exporter stuff
- in, that kinda thing should be pretty easy
+The relationship between these two classes is very odd. In particular,
+this line in Parameterized is insane:
-nothingmuch notes that all the constructs should be supported in the entirety of the use clause:
+ foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
- use Moose (
- has => foo (
- ....
- ),
- );
+Why does it need to loop through all parameterizable types? Shouldn't
+it know which parameterizable type it "came from"?
-and that if this usage style is used nothing is exported to the namespace.
+- Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
-- default should dclone()
+The Util module has _way_ too much functionality. It needs to be
+refactored so it's a thin sugar layer on top of the meta API. As it
+stands now, it does things like parse type names (and determine if
+they're valid), manage the registry, and much more.
-- auto_deref => 1 for auto-de-refing ARRAY and HASH attrs
+- Moose::Meta::Role::Application::*
+
+These class names are hardcoded throughout Moose, making replacing
+them very difficult.
+
+- Moose::Meta::Role & attributes
+
+The way a role stores attributes is nasty and not very
+introspectable. It should store some sort of object, possibly one that
+knows how to turn itself into a "real" attribute.
+
+- Anything with a _(meta)?class method
+
+Every method that returns a class name needs to become a rw attribute
+that can be set via the constructor.
+
+- The Moose::Error stuff
+
+This is sort of half-implemented. We still use Carp directly, and the
+internals can't decide how to throw an error (is it
+Moose->throw_error, __PACKAGE__->throw_error, what?).
+
+The internals need to be made consistent before we expose this to the
+rest of the world.
-------------------------------------------------------------------------------
TO PONDER
- Moose "strict" mode
use Moose 'strict'; This would allow us to have all sort of expensive tests
-which can be turned off in prod.
-
+which can be turned off in prod.
+
- Moose::Philosophy.pod
To explain Moose from a very high level
- moosedoc
We certainly have enough meta-information to make pretty complete POD docs.
-
-
-
+
+
+