I have been a fan of Class::Std but if I was to look at another module I would consider Class::InsideOut.

The more I worked with objects, the more I believe in using inside-out objects. It keeps you and your co-workers from being able to do stupid stuff(like directly accessing object data).

I also like to work with get_* and set_* methods rather than one method that can do both. A number of method generators don't have that option and don't play well with inside-out objects, relying more on blessed hashes.

Another issue is whether your object is going to represent data from a database. There are quite a few distributions for doing that, but I have not been happy with most of them and ended up writing my own. I have recently gone back and took a look at them again and one that is striking my fancy is Rose::DB::Object. The document and syntax is reasonably clear so I will probably start looking at that seriously.

In the rare case where I'm creating a truely generic class I'll usually reach for Class::Accessor::Fast to do the busy work. It's quick, light and gets the job done. I used to like Class::MethodMaker but I'm not a fan of where the module has gone since v2 came out.

-sam

I really like how object-orientation is implemented in Perl. Paraphrasing the manual, a class is nothing but a package and an object is nothing but a scalar blessed into a class. This gives you almost as much flexibility as rolling up your own object system in the first place, without most of the technical hassle. Granted, it took a long while to understand how things really work.

Object-orientation in Perl 5 in general seems as varied as it does in Scheme. CPAN contains many different models of object-orientation, some of which mimic Smalltalk, some Java, ... and all with a Perl twist. I tend to only use the barebones object system, because it's simple enough for me to understand properly. I'm not a huge fan of object-orientation in general (though as every technology, it does have its uses).

One day I will likely need something more sophisticated, but until then I'm happy being able to roll up my own automatic accessor method generator if I need those.

I may sound insane, but I like Perl 5's object model as it allows me to choose the right way for the design I'm interested in, while keeping everything Perlish enough. (Seeing that "Pure OO" languages tend to force their OO way-of-thinking on you).
On the other hand, I also like JavaScript's prototype system as well, so I might not be the best person to refer to.

Since you wrote that your web-application is a "great candidate for an OO style", I would suggest that you should pursue this idea before writing any code. Find out what style you wish to utilise and the object model that you'll seek, and then find the tools that satisfy your needs. Another way of doing this is actually finding the right tools (which components your web-application will use) and the API that goes with them. Most of CPAN's modules are already displaying a heavy OO API, which may suggest a way for you to work.

While Java (et al.)'s "Everything's an object (usually called Object)" state of mind isn't the only option out there, it seems that most people prefer their OO this way, making Moose a good choice, with its "Everything's a Moose::Object" style.

UPDATE: Just checked and found that in JavaScript Everything is, in fact, an Object.

While Java (et al.)'s "Everything's an object (usually called Object)" state of mind isn't the only option out there, it seems that most people prefer their OO this way, making Moose a good choice, with its "Everything's a Moose::Object" style.

Moose is more than just "Everything's a Moose::Object". We can also do prototype style OO, and if you are so inclined inside-out objects with MooseX::InsideOut. And honestly plain Moose is not nearly as "everything is an object" as when you use Moose::Autobox.

-stvn

Moose is more than just "Everything's a Moose::Object".

I was over-symplifying, of course, in the process of trying to cater for the OP's Java-based background.

We can also do prototype style OO

Now *that* would be interesting, although the URL you link to seems to be broken.

Software speaks in tongues of man; I debug, therefore I code.
Stop saying 'script'. Stop saying 'line-noise'.

Moose is gamey

use Test::More;

You are deliberating over what tool to use, but I would invite you to postpone that question and get busy writing a test suite.

What do you want your class to do? Have your test suite cover every interface method (including the constructor and the accessors), but above all convince yourself that a class that passes your tests will accomplish your goals.

I confess I find it hard to write tests when I really want to be coding the implementation, but I remind myself that

• tests are code too, and I enjoy writing them once I get started;
• coding the implementation is way more fun when I have a test suite in hand;
• managers asking after specs and documentation have been known to accept a well-commented test suite, or failing that, the test suite is a good outline for a requirements document.

Now you can safely pick a tool at random from among your favorite answers in this thread. You can even change your mind later and convert your classes to a different implementation. If your design is properly encapsulated, you'll be fine.

That said, I do have my own preference for inside-out or flyweight implementations. I think building classes in this way is like use strict. It catches dangerous practices (in this case, accessing your object's internals directly) at an earlier stage of development.