+== Todo for 2.0200
+
+=== Revise MetaRole API to reunify class/role metaroles:
+
+ apply_metaroles(
+ for => $meta,
+ roles => {
+ attribute => [...],
+ class => [...],
+ role_attribute => [ ... ],
+ }
+ );
+
+If the $meta is a class, we apply the roles to the class. If it's a role, we
+hold onto them and apply them as part of applying the role to a class.
+
+To make this all work nicely, we'll probably want to track the original role
+where a method was defined, just like we do with attributes currently. We'll
+also need to store method modifiers with their original role, which may mean
+adding some sort of Moose::Meta::Role::MethodModifier class.
+
+For each role-specific thing (methods, attributes, etc.) we should allow a
+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.
+
+=== Remove a bunch of deprecated crap
+
+See Moose::Manual::Delta for a list. Some of this is important to make merging
+Class::MOP into Moose core much easier. Other is just removing complexity
+needed to support ancient APIs.
+
+== Old todo (does anyone look at this?)
+
-------------------------------------------------------------------------------
-TODO
+BUGS
-------------------------------------------------------------------------------
-- roles
+-------------------------------------------------------------------------------
+FEATURES
+-------------------------------------------------------------------------------
+
+- DDuncan's Str types
+
+subtype 'Str'
+ => as 'Value'
+ => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
+ => optimize_as { defined($_[0]) && !ref($_[0]) };
-Need to figure out the details of composite roles
+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
- proxy attributes
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
+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)
-- compile time extends
-
-[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
-
-nothingmuch notes that all the constructs should be supported in the entirety of the use clause:
-
- use Moose (
- has => foo (
- ....
- ),
- );
-
-and that if this usage style is used nothing is exported to the namespace.
-
-- default should dclone()
-
-- subtype $anon_subtype => where { ... }
-
-[22:56] stevan sub mst_doesnt_like_to_type { (shift)->meta->attr->type_contstraint }
-[22:57] mst err
-[22:57] stevan :P
-[22:57] stevan are you wanting to reuse it or something?
-[22:57] stevan my $subtype = subtype 'Something' => where { ... };
-[22:58] stevan then you can do isa => $subtype
-[22:58] mst but I can't subtype it again
-[22:59] stevan mst: ahhh...
-[22:59] mst well, I can. but it suddenly gets very "long way round" ish
-[23:00] stevan my $constraint = Moose::Meta::TypeConstraint->new(
-[23:00] stevan name => $name || '__ANON__',
-[23:00] stevan parent => $parent,
-[23:00] stevan constraint => $check,
-[23:00] stevan message => $message,
-[23:00] stevan );
-[23:00] stevan yeah thats kinda the long way
-[23:00] stevan mst: what would you like it to be?
-[23:00] mst $parent = find_type_constraint($parent) if defined $parent;
-[23:00] mst if $parent is already a type constraint
-[23:00] mst skip that bit
-[23:00] stevan hmm
-[23:00] mst should be all you need to change
-[23:00] stevan yeah
-[23:01] stevan so you can then say
-[23:01] stevan subtype $anon => where { ... };
-[23:01] mst right
-[23:01] stevan ok
-
-- method keyword
-
-[23:37] mst more seriously, I'd still like a "method" keyword or something
-[23:37] mst method 'foo' => sub { ... };
-[23:38] stevan what would it do more than sub foo { ... }?
-[23:39] stevan I would like multimethods actually
-[23:39] mst almost exactly nothing, to begin with
-[23:39] stevan but thats just cause I love CLOS and am reading a book on Dylan now
-[23:40] stevan keyword squating :)
-[23:40] mst but if we need to hook stuff later it's bloody handy to already have people writing it that way
-[23:40] mst right
-...
-[23:49] mst oh, also: method 'has' => sub { ... } could squelch the redefine warning
-
-- Role excludes
-
-[17:00] stevan I am reading the new Fortress Spec
-[17:00] stevan http://research.sun.com/projects/plrg/fortress0903.pdf
-[17:00] stevan they have traits too
-[17:01] stevan and they have one cool feature which we might want to steal
-[17:01] stevan traits can "exclude" other traits
-[17:01] stevan which means they cannot be combined with other classes/roles which does() that trait
-[17:01] stevan the example they give is
-[17:01] stevan trait OrganicMolecule extends Molecule
-[17:01] stevan excludes { InorganicMolecule }
-[17:01] stevan end
-[17:01] stevan trait InorganicMolecule extends Molecule
-[17:01] stevan end
-[17:01] stevan this creates a set of mutually exclusive traits
-[17:02] stevan so that this:
-[17:02] stevan trait ScienceGoo extends { OrganicMolecule, InorganicMolocule } end
-[17:02] stevan would fail
-[17:02] stevan because OrganicMolecule, InorganicMolocule can never be used together
-[17:03] stevan I am thinking this is quite sane
-
+- 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
+
+-----------------------------------------------------------
+-- Type Constraints refactor
+-----------------------------------------------------------
+
+- add support for locally scoped TC
+
+This would borrow from MooseX::TypeLibrary to prefix the TC with the name
+of the package. It would then be accesible from the outside as the fully
+scoped name, but the local attributes would use it first. (this would need support
+in the registry for this).
+
+- look into sugar extensions
+
+Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This
+would allow custom metaclasses to provide roles to extend the sugar syntax with.
+
+(NOTE: Talk to phaylon a bit more on this)
+
+- allow a switch of some kind to optionally turn TC checking off at runtime
+
+The type checks can get expensive and some people have suggested that allowing
+the checks to be turned off would be helpful for deploying into performance
+intensive systems. Perhaps this can actually be done as an option to make_immutable?
+
+- misc. minor bits
+
+* make the errors for TCs use ->message
+* look into localizing the messages too
+* make ANON TCs be lazy, so they can possibly be subsituted for the real thing later
+* make ANON TCs more introspectable
+* add this ...
+
+#
+# Type Definition
+#
+subtype 'Username',
+ from 'Str',
+ where { (/[a-z][a-z0-9]+/i or fail('Invalid character(s)'))
+ and (length($_) >= 5 or fail('Too short (less than 5 chars)'))
+ }
+on_fail { MyException->throw(value => $_[0], message => $_[1]) };
+
+# fail() will just return false unless the call is made via
+$tc->check_or_fail($value);
+
+* and then something like this:
+
+subtype Foo => as Bar => where { ... } => scoped => -global;
+subtype Foo => as Bar => where { ... } => scoped => -local;
+
+# or
+
+subtype Foo => as Bar => where { ... } => in __PACKAGE__ ;
+
+# or (not sure if it would be possible)
+
+my $Foo = subtype Bar => where { ... };
+
+# ----------
+
+[17:10] <autarch> stevan: it should do it if I pass coerce => 1 as part of the attribute definition
+[17:12] <stevan> autarch: what I am not 100% sure of is how to tell it to deep coerce and when to not
+[17:13] <stevan> cause a basic coerce is from A to B
+[17:13] <autarch> hmm
+[17:13] <stevan> which is valid for collection types too
+[17:13] <stevan> deep coercion is what you are asking for
+[17:13] <autarch> yeah
+[17:13] <stevan> so perhaps we add deep_coerce => 1
+[17:13] <stevan> which will do it
+[17:13] <autarch> that's fine for me
+[17:13] <stevan> k
+
+coerce_deeply => 1 # reads better
+
+-------------------------------------------------------------------------------
+INTERNALS
+-------------------------------------------------------------------------------
+
+- rationalize all the get_X methods for classes (and roles)
+
+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.
+
+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
+
+- Moose::Meta::TypeConstraint::Parameter{izable,ized}
+
+The relationship between these two classes is very odd. In particular,
+this line in Parameterized is insane:
+
+ foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
+
+Why does it need to loop through all parameterizable types? Shouldn't
+it know which parameterizable type it "came from"?
+
+- Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
+
+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.
+
+- 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.
-
-
-
+
+
+
projects / gitmo/Moose.git / blobdiff