more changes
Stevan Little [Sat, 30 Sep 2006 19:31:03 +0000 (19:31 +0000)]
Changes
MANIFEST
lib/Moose.pm
lib/Moose/Cookbook/FAQ.pod
lib/Moose/Cookbook/WTF.pod
lib/Moose/Meta/Attribute.pm
t/018_import_unimport.t
t/019_method_keyword.t

diff --git a/Changes b/Changes
index f90c44f..40a9e35 100644 (file)
--- a/Changes
+++ b/Changes
@@ -11,6 +11,10 @@ Revision history for Perl extension Moose
         symbol table citizen and remove a dependency 
         (thanks Adam Kennedy)
 
+      **~~ removed experimental & undocumented feature ~~**
+      - commented out the 'method' and 'self' keywords, see the 
+        comments for more info.
+
     * Moose::Cookbook
       - added a FAQ and WTF files to document frequently 
         asked questions and common problems
index f2451a2..3b871fa 100644 (file)
--- a/MANIFEST
+++ b/MANIFEST
@@ -10,13 +10,13 @@ lib/Moose/Cookbook.pod
 lib/Moose/Object.pm
 lib/Moose/Role.pm
 lib/Moose/Cookbook/FAQ.pod
-lib/Moose/Cookbook/WTF.pod
 lib/Moose/Cookbook/Recipe1.pod
 lib/Moose/Cookbook/Recipe2.pod
 lib/Moose/Cookbook/Recipe3.pod
 lib/Moose/Cookbook/Recipe4.pod
 lib/Moose/Cookbook/Recipe5.pod
 lib/Moose/Cookbook/Recipe6.pod
+lib/Moose/Cookbook/WTF.pod
 lib/Moose/Meta/Attribute.pm
 lib/Moose/Meta/Class.pm
 lib/Moose/Meta/Instance.pm
@@ -73,9 +73,11 @@ t/054_util_type_coercion.t
 t/055_util_type_reloading.t
 t/056_util_more_type_coercion.t
 t/057_union_types.t
+t/058_union_types_and_coercions.t
 t/060_moose_for_meta.t
 t/070_more_attr_delegation.t
 t/071_misc_attribute_tests.t
+t/072_attr_dereference_test.t
 t/100_subtype_quote_bug.t
 t/101_subtype_conflict_bug.t
 t/102_Moose_Object_error.t
index 5005341..150bc31 100644 (file)
@@ -1,6 +1,4 @@
 
-use lib '/Users/stevan/Projects/Moose/Moose/Class-MOP/trunk/lib';
-
 package Moose;
 
 use strict;
@@ -142,23 +140,29 @@ use Moose::Util::TypeConstraints;
         },
         
         # NOTE:
-        # this is experimental for now ...
-        self => sub {
-            return subname 'Moose::self' => sub {};
-        },        
-        method => sub {
-            my $class = $CALLER;
-            return subname 'Moose::method' => sub {
-                my ($name, $method) = @_;
-                $class->meta->add_method($name, sub {
-                    my $self = shift;
-                    no strict   'refs';
-                    no warnings 'redefine';
-                    local *{$class->meta->name . '::self'} = sub { $self };
-                    $method->(@_);
-                });
-            };
-        },                
+        # this is experimental, but I am not 
+        # happy with it. If you want to try 
+        # it, you will have to uncomment it 
+        # yourself. 
+        # There is a really good chance that 
+        # this will be deprecated, dont get 
+        # too attached
+        # self => sub {
+        #     return subname 'Moose::self' => sub {};
+        # },        
+        # method => sub {
+        #     my $class = $CALLER;
+        #     return subname 'Moose::method' => sub {
+        #         my ($name, $method) = @_;
+        #         $class->meta->add_method($name, sub {
+        #             my $self = shift;
+        #             no strict   'refs';
+        #             no warnings 'redefine';
+        #             local *{$class->meta->name . '::self'} = sub { $self };
+        #             $method->(@_);
+        #         });
+        #     };
+        # },                
         
         confess => sub {
             return \&Carp::confess;
@@ -291,9 +295,6 @@ to be evolving. Much of the outer API is stable, but the internals
 are still subject to change (although not without serious thought 
 given to it).  
 
-For more details, please refer to the L<FUTURE PLANS> section of 
-this document.
-
 =head1 DESCRIPTION
 
 Moose is an extension of the Perl 5 object system. 
index 51218bf..6b2b1fd 100644 (file)
@@ -7,6 +7,80 @@ Moose::Cookbook::FAQ - Frequenty asked questions about Moose
 
 =head1 FREQUENTLY ASKED QUESTIONS
 
+=head2 Module Stability
+
+=head3 Is Moose "production ready"?
+
+Yes and No. Currently I have one web application in production 
+using Moose, and at $work we are re-writing our core offering to 
+use Moose. Several other people on #moose either have sites in 
+production which use Moose, or are in the process of deploying 
+sites which use Moose. 
+
+The biggest barrier to widespread use of Moose in production 
+right now is speed of development and speed of execution. 
+
+Since development is still happening, regular upgrades are a 
+fact of life. This can be hairy in production, so if this makes 
+you quake with fear, you might want to wait a few months.
+
+Then comes speed of execution. Moose is actually pretty fast, 
+and makes great effort to stay out of your way when you don't 
+want it there. However, certain parts of Moose are slow, such 
+as compile time setup, introspection and object construction 
+(only because it uses introspection). See L<Is Moose slow?> 
+below for a deeper discussion on the subject.
+
+=head3 Is Moose's API stable?
+
+Yes and No. The external API, the one 90% of users will interact
+with, is B<very stable> and any changes B<will be 100% backwards 
+compatible>. The introspection API is I<mostly> stable, I still 
+reserve the right to tweak that if needed, but I will do my 
+absolute best to maintain backwards comptability here as well.
+
+=head3 Is Moose slow?
+
+Again, this one is tricky, so Yes I<and> No.
+
+First let me say that I<nothing> in life is free, and that some 
+Moose features do cost more than others. It is also the 
+policy of Moose to B<only charge you for the features you use>, 
+and to do our absolute best to not place any extra burdens on 
+the execution of your code for features you are not using. 
+
+Next, I will point out again that we are still in the "early 
+adopter" phase, so speed it not that important yet. We are 
+actually optimizing for "theoretical correctness" first, and 
+we will optimize for speed later. It has been our experience 
+that taking this approach allows for greater optimization 
+capacity. 
+
+And lastly, I want to reassure the speed junkies out there that 
+we B<are> working on it. 
+
+We have the immutable classes in Class::MOP, but which are not 
+yet integrated with Moose. These allow you to "close" a class 
+and then for many of it's more expensive methods to me memoized. 
+Our tests indicated a performance comparable (and in some 
+instances exceeding) that of hand-coded Perl.
+
+We are also discussing and experimenting with L<Module::Compile>, 
+and the idea of compiling highly optimized C<.pmc> files. And we 
+have also mapped out some core methods as canidates for conversion 
+to XS. 
+
+=head3 When will Moose be 1.0 ready?
+
+I expect (barring unforseen circumstances) that Moose will be 
+at 1.0 by the end of this year (2006). Which means that it will be 
+completely stable and provide a number of optimization options to 
+suit the need for speed. 
+
+Will I have addressed all your concerns by then? Will all the 
+features you want be included? I don't know unless you tell me, 
+so come over to #moose and we can talk.
+
 =head2 Constructors
 
 =head3 How do I write custom constructors with Moose?
index 0c0ccf2..61e4207 100644 (file)
@@ -7,6 +7,27 @@ Moose::Cookbook::WTF - For when things go wrong with Moose
 
 =head1 COMMON PROBLEMS
 
+=head2 Speed
+
+=head3 Why is my code taking so long to load?
+
+Moose has a fairly heavy compile time burden, which it 
+inherits from Class::MOP. If load/compile time is a 
+concern for your application, Moose may not be the 
+right tool for you. 
+
+Although, you should note that we are exploring the 
+use of L<Module::Compile> to try and reduce this problem, 
+but nothing is ready yet.
+
+=head3 Why are my objects taking so long to construct?
+
+Moose uses a lot of introspection when constructing an 
+instance, and introspection can be slow. However, this 
+is a temporary problem, and is already solved in 
+Class::MOP by making classes immutable. However immutable 
+support in Moose is not ready yet, but will be soon.
+
 =head2 Constructors
 
 =head2 Accessors
index 2bbc6ad..a6fd964 100644 (file)
@@ -66,9 +66,14 @@ sub clone_and_inherit_options {
                    (defined $type_constraint)
                        || confess "Could not find the type constraint '" . $options{isa} . "'";
                }
+               # NOTE:
+               # check here to see if the new type 
+               # is a subtype of the old one
                ($type_constraint->is_subtype_of($self->type_constraint->name))
                    || confess "New type constraint setting must be a subtype of inherited one"
+                       # iff we have a type constraint that is ...
                        if $self->has_type_constraint;
+               # then we use it :)
                $actual_options{type_constraint} = $type_constraint;
         delete $options{isa};
     }
index 914604b..39c45ad 100644 (file)
@@ -3,7 +3,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 27;
+use Test::More tests => 23;
 
 BEGIN {
     use_ok('Moose');           
@@ -15,11 +15,10 @@ my @moose_exports = qw(
     before after around
     override
     augment
-    method
 );
 
 my @moose_not_unimported = qw(
-    super inner self
+    super inner
 );
 
 {
index 763006c..9384c5d 100644 (file)
@@ -3,12 +3,21 @@
 use strict;
 use warnings;
 
-use Test::More no_plan => 1;
+use Test::More tests => 1;
 
 BEGIN {
     use_ok('Moose');
 }
 
+1;
+
+__END__
+
+=pod
+
+I dont think I am going to keep this feature, but 
+the tests are commented out for now.
+
 {
     package Foo;
     use Moose;
@@ -34,4 +43,6 @@ isa_ok($foo, 'Foo');
 
 is($foo->greetings('World'), 'Hello, World', '... got the right value from greetings');
 is($foo->greet_world_from('Stevan'), 'Hello, World from Stevan', '... got the right value from greet_world_from');
-is($foo->greet_world_from_me, 'Hello, World from Stevan', '... got the right value from greet_world');
\ No newline at end of file
+is($foo->greet_world_from_me, 'Hello, World from Stevan', '... got the right value from greet_world');
+
+=cut
\ No newline at end of file