Re^2: Class confusion when testing using ref()

All the modules mentioned are “state of the art” since they are all actively maintained and really quite nice. Also missed Moo, and for bleeding edge fun you might look at Moops. Moose does more than the others; see Class::MOP for why/how. It’s also the slowest (really start up is the major issue, it’s not “slow” exactly once compiled and running) and the others through their minimalism achieve, maybe… subjective, cleaner interfaces and extensions. Mouse with XS is the fastest by a lot. I’ve been reaching for Moo most of the time. I didn’t know Mo had grown so much since it was sort of what I saw as a joke response to it all. I would probably use Moops for personal projects if I had the tuits for personal projects right now.

On that note I’d like to say that tobyink is really quite an excellent—and prodicious!—software designer. See also, Type::Tiny.

Comment on Re^2: Class confusion when testing using ref()

Replies are listed 'Best First'.
Re^3: Class confusion when testing using ref() by tobyink (Canon) on Jan 07, 2014 at 16:14 UTC
How could I possibly not ++ the above? Your_Mother, your cheque is in the post. ;-) Anyway, my personal opinion is for OO to default to Moo, and only consider other options if you have special requirements. Use Moose if you have requirements for introspection of your classes. But also consider whether introspection is really necessary. For example, if you want to interrogate a class to find which attributes accept, say, an integer, rather than using Moose's meta object protocol to generate the list, you could just add a method to the class called which returns a hard-coded list of such attributes, a la `sub integer_attributes { return qw(cell_height cell_width) }` Use Moose if you want to take advantage of the many MooseX modules on CPAN. (There's an increasing number of MooX modules though.) Use Moose if your project has dependencies on other projects that already use Moose. Not that using Moo would be a technical problem - Moo and Moose integrate very well. However, it saves people from installing both Moo and Moose, and you may save a little memory by using just one OO system. However, some prominent projects such as Throwable have moved from Moose to Moo. Consider Mouse if speed of generated methods (constructors, accessors) is an important concern, because Mouse implements them in C. Of course, for many projects, it's the methods you write yourself in pure Perl that do the bulk of the work. Moo (and also Moose if you install MooseX::XSAccessor) can sometimes, optionally generate XS accessors for you (but not constructors). Use Class::Tiny or Role::Tiny if your requirements are very basic, and you want to keep dependencies at a minimum. Consider Moops if you can tolerate its very large dependency list. (But it has fewer dependencies than MooseX::Declare.) Something I use Moops for is rapid prototyping before backporting to plain Moo. `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Class confusion when testing using ref()
by tobyink (Canon) on Jan 07, 2014 at 16:14 UTC

How could I possibly not ++ the above? Your_Mother, your cheque is in the post. ;-)

Anyway, my personal opinion is for OO to default to Moo, and only consider other options if you have special requirements.

Use Moose if you have requirements for introspection of your classes.

But also consider whether introspection is really necessary. For example, if you want to interrogate a class to find which attributes accept, say, an integer, rather than using Moose's meta object protocol to generate the list, you could just add a method to the class called which returns a hard-coded list of such attributes, a la sub integer_attributes { return qw(cell_height cell_width) }
Use Moose if you want to take advantage of the many MooseX modules on CPAN. (There's an increasing number of MooX modules though.)
Use Moose if your project has dependencies on other projects that already use Moose. Not that using Moo would be a technical problem - Moo and Moose integrate very well. However, it saves people from installing both Moo and Moose, and you may save a little memory by using just one OO system. However, some prominent projects such as Throwable have moved from Moose to Moo.
Consider Mouse if speed of generated methods (constructors, accessors) is an important concern, because Mouse implements them in C. Of course, for many projects, it's the methods you write yourself in pure Perl that do the bulk of the work.

Moo (and also Moose if you install MooseX::XSAccessor) can sometimes, optionally generate XS accessors for you (but not constructors).
Use Class::Tiny or Role::Tiny if your requirements are very basic, and you want to keep dependencies at a minimum.
Consider Moops if you can tolerate its very large dependency list. (But it has fewer dependencies than MooseX::Declare.)

Something I use Moops for is rapid prototyping before backporting to plain Moo.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

[reply]
[d/l]