TODO

   1 -------------------------------------------------------------------------------
   2 TODO
   3 -------------------------------------------------------------------------------
   4
   5 - roles
   6
   7 Need to figure out the details of composite roles
   8
   9 - type unions
  10
  11 Add support for doing it with Classes which do not have
  12 a type constraint yet created
  13
  14 - type intersections
  15
  16 Mostly just for Roles
  17
  18 - inherited slot specs
  19
  20 'does' can be added to,.. but not changed
  21 (need type unions for this)
  22
  23 - proxy attributes
  24
  25 a proxied attribute is an attribute
  26 which looks like an attribute,
  27 talks like an attribute, smells
  28 like an attribute,.. but if you
  29 look behind the curtain,.. its
  30 over there.. in that other object
  31
  32 (... probably be a custom metaclass)
  33
  34 - compile time extends
  35
  36 [00:39]         sri         but maybe a better syntax for compile time extends
  37 [00:39]         stevan  I have been pondering that actually
  38 [00:39]         sri         use Moose extends => Foo::Bar
  39 [00:40]         stevan  I think now that we have the Sub::Exporter stuff
  40                     in, that kinda thing should be pretty easy
  41
  42 nothingmuch notes that all the constructs should be supported in the entirety of the use clause:
  43
  44     use Moose (
  45         has => foo (
  46             ....
  47         ),
  48     );
  49
  50 and that if this usage style is used nothing is exported to the namespace.
  51
  52 - default should dclone()
  53
  54 - subtype $anon_subtype => where { ... }
  55
  56 [22:56]         stevan  sub mst_doesnt_like_to_type { (shift)->meta->attr->type_contstraint }
  57 [22:57]         mst     err
  58 [22:57]         stevan  :P
  59 [22:57]         stevan  are you wanting to reuse it or something?
  60 [22:57]         stevan  my $subtype = subtype 'Something' => where { ... };
  61 [22:58]         stevan  then you can do isa => $subtype
  62 [22:58]         mst     but I can't subtype it again
  63 [22:59]         stevan  mst: ahhh...
  64 [22:59]         mst     well, I can. but it suddenly gets very "long way round" ish
  65 [23:00]         stevan  my $constraint = Moose::Meta::TypeConstraint->new(
  66 [23:00]         stevan              name       => $name || '__ANON__',
  67 [23:00]         stevan              parent     => $parent,
  68 [23:00]         stevan              constraint => $check,
  69 [23:00]         stevan              message    => $message,
  70 [23:00]         stevan          );
  71 [23:00]         stevan  yeah thats kinda the long way
  72 [23:00]         stevan  mst: what would you like it to be?
  73 [23:00]         mst     $parent = find_type_constraint($parent) if defined $parent;
  74 [23:00]         mst     if $parent is already a type constraint
  75 [23:00]         mst     skip that bit
  76 [23:00]         stevan  hmm
  77 [23:00]         mst     should be all you need to change
  78 [23:00]         stevan  yeah
  79 [23:01]         stevan  so you can then say
  80 [23:01]         stevan  subtype $anon => where { ... };
  81 [23:01]         mst     right
  82 [23:01]         stevan  ok
  83
  84 - method keyword
  85
  86 [23:37]         mst     more seriously, I'd still like a "method" keyword or something
  87 [23:37]         mst     method 'foo' => sub { ... };
  88 [23:38]         stevan  what would it do more than sub foo { ... }?
  89 [23:39]         stevan  I would like multimethods actually
  90 [23:39]         mst     almost exactly nothing, to begin with
  91 [23:39]         stevan  but thats just cause I love CLOS and am reading a book on Dylan now
  92 [23:40]         stevan  keyword squating :)
  93 [23:40]         mst     but if we need to hook stuff later it's bloody handy to already have people writing it that way
  94 [23:40]         mst     right
  95 ...
  96 [23:49]         mst     oh, also: method 'has' => sub { ... } could squelch the redefine warning
  97
  98 - Role excludes
  99
 100 [17:00]         stevan  I am reading the new Fortress Spec
 101 [17:00]         stevan  http://research.sun.com/projects/plrg/fortress0903.pdf
 102 [17:00]         stevan  they have traits too
 103 [17:01]         stevan  and they have one cool feature which we might want to steal
 104 [17:01]         stevan  traits can "exclude" other traits
 105 [17:01]         stevan  which means they cannot be combined with other classes/roles which does() that trait
 106 [17:01]         stevan  the example they give is
 107 [17:01]         stevan  trait OrganicMolecule extends Molecule
 108 [17:01]         stevan      excludes { InorganicMolecule }
 109 [17:01]         stevan  end
 110 [17:01]         stevan  trait InorganicMolecule extends Molecule
 111 [17:01]         stevan  end
 112 [17:01]         stevan  this creates a set of mutually exclusive traits
 113 [17:02]         stevan  so that this:
 114 [17:02]         stevan  trait ScienceGoo extends { OrganicMolecule, InorganicMolocule } end
 115 [17:02]         stevan  would fail
 116 [17:02]         stevan  because OrganicMolecule, InorganicMolocule can never be used together
 117 [17:03]         stevan  I am thinking this is quite sane
 118
 119 -------------------------------------------------------------------------------
 120 TO PONDER
 121 -------------------------------------------------------------------------------
 122
 123 - Moose "strict" mode
 124
 125 use Moose 'strict'; This would allow us to have all sort of expensive tests
 126 which can be turned off in prod.
 127
 128 - Moose::Philosophy.pod
 129
 130 To explain Moose from a very high level
 131
 132 - moosedoc
 133
 134 We certainly have enough meta-information to make pretty complete POD docs.
 135
 136
 137