From: Aankhen Date: Tue, 1 May 2007 07:26:55 +0000 (+0000) Subject: Moose::Cookbook::Recipe2: X-Git-Tag: 0_21~4 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=c6182301b652a3e5581eaf55b67f291ee3c3ceac;p=gitmo%2FMoose.git Moose::Cookbook::Recipe2: * grammar tweaks. --- diff --git a/lib/Moose/Cookbook/Recipe2.pod b/lib/Moose/Cookbook/Recipe2.pod index 7ec039b..51aec81 100644 --- a/lib/Moose/Cookbook/Recipe2.pod +++ b/lib/Moose/Cookbook/Recipe2.pod @@ -43,15 +43,15 @@ Moose::Cookbook::Recipe2 - A simple B example =head1 DESCRIPTION -In the first recipe we showed how to build basic Moose classes -whose attributes had various accessor schemes and built in -type constraints. However our objects were very data-oriented, -and did not have many behavioral aspects to them (i.e. - methods). -In this recipe, we will expand upon the concepts from the first -recipe and give a more realistic scenario of more behavior -oriented classes. - -We are using an example of a bank account, which has a standard +In the first recipe we demonstrated the construction of basic +Moose classes whose attributes had various accessor schemes and +builtin type constraints. However, our objects were very data- +oriented, and did not have many behavioral aspects (i.e. methods) +to them. In this recipe, we will expand upon the concepts from +the first recipe and give a more realistic scenario of more +behavior oriented classes. + +We are using the example of a bank account, which has a standard account (you can deposit money, withdraw money and check your current balance), and a checking account which has optional overdraft protection. The overdraft protection will protect the @@ -59,8 +59,8 @@ owner of the checking account by automatically withdrawing the needed funds from the overdraft account to ensure that a check will not bounce. -Now, onto the code. The first class B introduces a -new attribute feature, that of a default value. +Now, onto the code. The first class, B, introduces a +new attribute feature: a default value. has 'balance' => (isa => 'Int', is => 'rw', default => 0); @@ -71,33 +71,32 @@ B that is created will have its C slot initialized to C<0>. Very simple really :) Next come the methods. The C and C methods -should be fairly self explanatory, they are nothing specific to +should be fairly self-explanatory; they are nothing specific to Moose, just your standard Perl 5 OO. Now, onto the B class. As you know from the first recipe, the keyword C sets a class's superclass relationship. Here we see that B is a B. The next line introduces yet another new aspect -of Moose, that of class based type-constraints. +of Moose, that of class-based type-constraints: has 'overdraft_account' => (isa => 'BankAccount', is => 'rw'); Up until now, we have only had C type constraints, which -(as I said in the first recipe) is a built-in type constraint +(as I said in the first recipe) is a builtin type constraint that Moose provides for you. The C type constraint -is new, and was actually defined at the moment we created the +is new, and was actually defined the moment we created the B class itself. In fact, for every Moose class that -you define, a corresponding type constraint will be created for -that class. This means that in the first recipe, a C and -C type constraint were created, and in this recipe, both -a C and a C type constraint were -created. Moose does this as a convenience for you so that your -class model and the type constraint model can both be kept in -sync with one another. In short, Moose makes sure that it will -just DWIM (1). +you define, a corresponding type constraint will be created. This +means that in the first recipe, both C and C type +constraints were created, and in this recipe, both C +and C type constraints were created. Moose does +this as a convenience so that your class model and the type +constraint model can be kept in sync with one another. In short, +Moose makes sure that it will just DWIM (1). Next, we come to the behavioral part of B, and -again we see a method modifier, but this time we have a C +again we see a method modifier, but this time it is a C modifier. before 'withdraw' => sub { @@ -136,15 +135,15 @@ pseudo-package. So the above method is equivalent to the one here. The benefits of taking the method modifier approach is that the author of the B subclass does not need to remember to call C and to pass it the C<$amount> argument. -Instead the method modifier assures that all arguments make it +Instead the method modifier ensures that all arguments make it to the superclass method correctly. But this is actually more than just a convenience for forgetful programmers, it also helps isolate subclasses from changes in the superclasses. For instance, if B were to add an additional argument of some kind, the version of B which uses C would not pass that extra argument -correctly. Whereas the method modifier version would automatically pass -along all arguments correctly. +correctly, whereas the method modifier version would automatically +pass along all arguments correctly. Just as with the first recipe, object instantiation is a fairly normal process, here is an example: @@ -160,12 +159,12 @@ these classes can be found in the F test file. =head1 CONCLUSION -The aim of this recipe was to take the knowledge learned in the -first recipe and expand upon it within a more realistic use case. -I hope that this recipe has accomplished this goal. The next -recipe will expand even more upon the capabilities of attributes -in Moose to create a behaviorally sophisticated class almost -entirely defined by attributes. +The aim of this recipe was to take the knowledge gained in the +first recipe and expand upon it with a more realistic use case. I +hope that this recipe has accomplished this goal. The next recipe +will expand even more upon the capabilities of attributes in Moose +to create a behaviorally sophisticated class almost entirely +defined by attributes. =head1 FOOTNOTES @@ -174,9 +173,9 @@ entirely defined by attributes. =item (1) Moose does not attempt to encode a class's is-a relationships -within the type constraint hierarchy. Instead Moose just considers -the class type constraint to be a subtype of C, and -specializes the constraint check to allow for subclasses. This +within the type constraint hierarchy. Instead, Moose just +considers the class type constraint to be a subtype of C, +and specializes the constraint check to allow for subclasses. This means that an instance of B will pass a C type constraint successfully. For more details, please refer to the L documentation. @@ -190,8 +189,7 @@ please refer to the L documentation. =item Acknowledgment The BankAccount example in this recipe is directly taken from the -examples in this chapter of "Practical Common Lisp". A link to that -can be found here: +examples in this chapter of "Practical Common Lisp": L