可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I'm still relatively new to Perl Programming, but I know how Perl 5 OO basically works. However, I have never created any project with Perl 5 OO, so I'm quite sure I will run into many pitfalls.
Recently I discovered the hype about the Moose module. I checked out some documentation on CPAN and I found it to be quite interesting and helping me as a developer a lot. Additionally, it seems to be very stable and reliable.
Should I rather intensify working with the basic Perl 5 OO syntax until I feel very familiar with it (to know what's going on behind the stages), or do you think I should rather go ahead and directly start developing applications using Moose? Or should I even give Mouse a try?
Any thoughts and experiences on that are appreciated.
Thanks in advance!
回答1:
As everyone else has pointed out learning the basics of how OO in Perl is done will help you, not only with most non-moose packages out there but also with Moose itself since deep down Moose basically just uses a standard Perl OO layout. Basically once you're comfortable you understand what Moose::Manual::Unsweetend is showing you'll have a reasonable grasp of the OO principles in Perl. Damian Conway's Object Oriented Perl book is an excellent introduction to Object Orientation period not just Perl's flavor(s). I'd highly suggest reading it, or at least the first half of it.
Finally there is no reason to use Mouse (an alternative to Moose) unless you fall into two very specific categories, you have hard start up time constraints or hard dependency requirements. If you don't fall into those two places Moose will almost always be a better answer.
Disclosure: I'm a core Moose developer, and have worked on and with Mouse.
回答2:
Most of the Perl world is not Moose, so you'll still need the basics to use all of the other modules.
回答3:
IMHO I would learn Moose first. Why? Yes, most Perl OO is not done doing Moose. Yes, Moose is slow (though try Mouse). Yes, there's lots of practical reasons why you're going to have to eventually learn to do it the hard way. But there's one overriding reason.
Because Perl's way of doing OO warps your brain.
The point is to learn good OO, not Perl's OO. Once you understand OO programming as a concept them you can apply the technique to any specific language. The reverse is not so true.
Perl's stock OO doesn't give you much at all. You have to build all your pieces yourself. You have to learn all the little details of how everything works. It teaches you broken concepts like "objects are just magic hash references" and "methods are just subroutines with $self as the first argument" and "classes are just packages". In short, Perl OO teaches you to pay attention to how everything works which is the EXACT OPPOSITE of how OO is supposed to work.
OO is about NOT caring about the details of how things work. The whole point of an object is its a THING you ASK to do work and you don't care how it does it. A good object is like a good janitor. You ask the janitor to clean the floor, and then you walk away. When you come back, the floor is cleaned. It doesn't matter if the janitor used a mop, a toothbrush, their tongue or tore up the whole floor and installed a new one. The floor is clean and that's all that matters.
Furthermore, about the only way of composing objects that Perl gives you out of the box is inheritance. Inheritance is what everyone learns first when learning OO and its dangerous and mind warping. OO is OBJECT oriented, not inheritance oriented. The important thing is the encapsulation of the object, not that you can share code. A newbie programmer with inheritance is like giving a gun to the baby. Multiple inheritance is like giving them a howitzer. Newbies immediately leap to inheritance and created great tangled hierarchies. They never learn about delegation or composition or roles or mixins or any of the half dozen much better ways of letting objects share and build behaviors.
Moose gives you all that, out of the box, so you can focus on writing objects and not on writing an OO system.
Once you've learned how to do OO right then you can learn Perl's OO and how to do it twenty other ways, twelve of them wrong.
回答4:
Honestly, I am not sure how valuable knowledge of Perl's raw OO primitives is for writing new code anymore. I have not used @ISA or "use base" or "bless" in my code for a very long time; any OO I do is via the Moose MOP. (I do rebless instances, of course, but I use $meta->rebless_instance instead of just "bless". Much cleaner!)
Anyway, I would teach yourself Moose first. It is easy to get started and get productive right away, and you can pick up the details as you become more proficient in Perl and programming in general.
As an example:
#!/usr/bin/env perl
use strict;
use warnings;
use feature ':5.10'; # for 'say'
use MooseX::Declare;
class Point {
has [qw/x y/] => ( is => 'ro', isa => 'Num', required => 1 );
method new_from_ordered_pair(ClassName $class: Num $x, Num $y){
return $class->new( x => $x, y => $y );
}
method distance(Point $a: Point $b){
return sqrt( ($a->x - $b->x)**2 + ($a->y - $b->y)**2 );
}
}
my $origin = Point->new_from_ordered_pair(0,0);
my $point = Point->new_from_ordered_pair(3,4);
say '(3,4) is '. $point->distance($origin). ' units away from the origin.';
Notice how there is no more fighting with the details of Perl's implementation. You can easily worry about the details of your program instead of how to do OO in Perl. You don't even have to make a "Point.pm" file, you can have the class definition inline.
I also think this code would be immediately understandable to almost any programmer -- even ones not familiar with the details of Perl or Moose (or MooseX::Declare).
(BTW, this example worked out a bit oddly with the ":" syntax in the method signatures. Normally, you get an instance of yourself called $self as the first arg. If you supply something else before a : in the signature, you can change the type and name of the variable. I also wrote "new_from_ordered_pair" so that you wouldn't have to type x => $x, y => $y
as the arguments to new every time. This is just sugar that I think is nice; nothing magical is happening here.)
Finally, you get a lot here "for free". Try these, and note the helpful error messages:
Point->new; # x is required
Point->new_from_ordered_pair('foo', 'bar'); # x needs to be a number
$point->distance('some string'); # $b needs to be a Point
You get all this for free, and it makes debugging your program easier. There is no reason to avoid it, it really makes programming more enjoyable (and it makes your program more reliable... for free!)
Oh, one more thing. With Moose, you can introspect your classes. This might not be important right away, but it can be nice to have. Open Devel::REPL, type 'do "test.pl"' to load the Point class, and then say something like:
map { $_->name } Point->meta->get_all_attributes;
The result is ['x', 'y']
. Without having the source code, you can find out what attributes the class has. Try doing that with "plain" Perl OO. (This sort of thing is what makes the rich MooseX:: namespace possible. You might not need introspection, but you will enjoy the ability to use reliable modules from CPAN.)
回答5:
Moose is good, but the decision about learning it depends on what your goals are.
If you just want to write your own programs using OO techniques, then it could very well be worth diving into Moose (and worrying about other OO techniques later)
If you want to become "a Perl programmer", then you'll encounter more non-Moose OO code then Moose OO code, so you should learn to deal with coding without Moose first. I suggest Object Oriented Perl by Damian Conway as a good starting point.
回答6:
Get comfortable with the basics first. Unless you've done a lot of OO JavaScript, OO Perl is going to seem a little strange, and some of the things that Moose or any other library does may seem wierd.
回答7:
I've started using Moose and like it quite a bit. I do agree with the other posts that say you should still learn how to do OO perl w/o Moose. But that tends to be difficult and there are many ways you can go about doing that. I think if you're starting a new project then Moose is the way to go.
I've also used Object::InsideOut, which is a lot like Moose and also helps protect your object variables from being tampered with.
Another note, I understand that Perl 6 objects will be much like Moose objects.. so learning Moose will prep you for Perl 6.
回答8:
Learn OOP that comes with Perl before Moose. This will make it a lot easier for you in the long run.
回答9:
This was going to be a comment on Schwern's post, but it grew.
I would say that moose is slower than "normal" Perl OO, but firstly this is not terribly important for most code (premature optimisation) and secondly if you do __PACKAGE__->make_immutable
then a lot of the runtime overhead is removed anyway.
I'm with the "learn Moose first" gang. I like to remain willfully ignorant of Perl OO details for the kind of code that I write (data management and simple apps), and so I tend to use Moose for everything, even stuff I would have done procedurally in the past, because it makes a lot of the mechanics of the programming much easier
回答10:
Moose is useful, but you may still want to learn about perl OO proper to shield yourself from the leaky abstraction problem.
Perl OO itself is rather hairy, but this book makes it very easy to digest: Intermediate Perl. Highly recommended.
回答11:
Lots of useful answers above. The only thing I can add is that the Moose manual is now available to buy as a book or PDF. If you're learning or just using Moose, its a useful reference guide and it's printed in pretty typography.
- Moose Manual - printed book
Disclosure: we created the book (Mr Monkey), though we didn't write it (that was Dave Rolsky
and Stevan Little).