[gitmo/MooseX-Role-Parameterized.git] / TODO

+ We need to reimplement all of the keywords of Moose::Role. So far I have "has"
  (and added "method" for various reasons). They need to operate on
  $CURRENT_METACLASS instead of caller.

+ There is literally zero documentation.

+ Tests could be improved too! Failing tests more than welcome.

+ A good motivating example. Different serialization formats sucks.

+ Moose::Exporter should have a with_meta option which does with_caller but also
  initializes the metaclass, since that's the most common case for us (and
  probably others).

+ Figure out a plan for alias, excludes, and other parameters that roles
  currently support.
    - I'm fine with saying either of:
        * "You can't have exclusion; make it a parameter"
        * "You cannot have parameters named alias or excludes; they
          already have meaning"
    - The current implementation is closer to the latter. (we pass the args to
      both parameter construction and parameterized-role application)
    - We don't enforce that parameters cannot be named alias or excludes though.

+ Parameters is an empty superclass. Is there anything interesting we can stick
  in there?
Commit	Line	Data
2f5d78aa	1	+ We need to reimplement all of the keywords of Moose::Role. So far I have "has"
	2	(and added "method" for various reasons). They need to operate on
	3	$CURRENT_METACLASS instead of caller.
	4
	5	+ There is literally zero documentation.
	6
dabb4418	7	+ Tests could be improved too! Failing tests more than welcome.
dabb4418	8
2f5d78aa	9	+ A good motivating example. Different serialization formats sucks.
	10
	11	+ Moose::Exporter should have a with_meta option which does with_caller but also
	12	initializes the metaclass, since that's the most common case for us (and
	13	probably others).
	14
	15	+ Figure out a plan for alias, excludes, and other parameters that roles
	16	currently support.
	17	- I'm fine with saying either of:
	18	* "You can't have exclusion; make it a parameter"
	19	* "You cannot have parameters named alias or excludes; they
	20	already have meaning"
	21	- The current implementation is closer to the latter. (we pass the args to
	22	both parameter construction and parameterized-role application)
	23	- We don't enforce that parameters cannot be named alias or excludes though.
	24
	25	+ Parameters is an empty superclass. Is there anything interesting we can stick
	26	in there?
	27