Re^2: To Moose or not To Moose.. ?

I would not use Moose for anything complex either. The deal with Moose not necessarily that it is heavy handed. It has to do with the notion that it is creating a new paradigm and idiomatic system inside of Perl that is actually much more constraining than what Perl already provides itself. Moose provides a Metaobject Protocol on top of Perl's Meta Protocol, so it's actually constraining you in many ways. This doesn't just apply to Moose. It applies to all MOPs. You end up creating gobs of predefined and implied declarations rather than just cleanly creating a set of blessed object interfaces. What you end up with is decidedly not Perl, and I am not sure what the payout is.

What I tend to do if I want to easily create a set of accessors based off of fields names is to do so using one of the many accessor create modules on CPAN. It truly takes very little code to turn a list of field names into some autogenerated get/set methods, so just as often I use my own code snippet to make it happen.

Comment on Re^2: To Moose or not To Moose.. ?

Replies are listed 'Best First'.
Re^3: To Moose or not To Moose.. ? by arkturuz (Curate) on Jun 10, 2014 at 08:30 UTC
It has to do with the notion that it is creating a new paradigm and idiomatic system inside of Perl that is actually much more constraining than what Perl already provides itself. This is what you want when doing complex stuff. You can, of course, limit your data and application behavior with plain old Perl, but in the end it's too much work. Perl is not exactly at the top of elegant OO approach by itself. I've done some mildly complex stuff with Moose in the past and it worked great. I'll certainly use it in the future, although there are simpler alternatives these days. and I am not sure what the payout is The payout is simpler code, easier to understand at glance, easier to maintain and extend. For simple stuff, Moose is overkill, but for anything complex (in terms of behavior, not just in terms of pure amount of object data, methods etc) Moose is a good solution.	[reply]

Replies are listed 'Best First'.

Re^3: To Moose or not To Moose.. ?
by arkturuz (Curate) on Jun 10, 2014 at 08:30 UTC

It has to do with the notion that it is creating a new paradigm and idiomatic system inside of Perl that is actually much more constraining than what Perl already provides itself.

This is what you want when doing complex stuff. You can, of course, limit your data and application behavior with plain old Perl, but in the end it's too much work. Perl is not exactly at the top of elegant OO approach by itself. I've done some mildly complex stuff with Moose in the past and it worked great. I'll certainly use it in the future, although there are simpler alternatives these days.

and I am not sure what the payout is

The payout is simpler code, easier to understand at glance, easier to maintain and extend. For simple stuff, Moose is overkill, but for anything complex (in terms of behavior, not just in terms of pure amount of object data, methods etc) Moose is a good solution.

[reply]