Why use Perl OO simply as a data encapsulation technique?

Question

I am trying to use a Perl API that has been written to use the Moose OO system but there is absolutely no inheritance, aggregation, or composition involved between the objects.

And, apart from a single optional role for debugging, there are no roles or mixins involved as well.

As far as I can see at the moment, using Moose just seems to add a massive amount of complication and compile-time overhead for very little benefit.

Why would you use Moose, or OO, as a simple method of encapsulation instead of using the far simpler technique of packaging the code into Perl modules?

Just to clarify, I am totally convinced of the many advantages of using Moose to do OO in Perl correctly and completely. I just don't understand why use OO at all as a simple encapsulation technique? I am not after a subjective argument in favour or otherwise of Perl OO. I am hoping that I am missing some advantage to using the OO paradigm here that I am simply not seeing atm.

This question has an excellent series of points about data encapsulation in Perl. N.B. I am not talking about enforced encapsulation where the system stops you from looking where you shouldn't, more about just only exposing methods in a package that manipulate the data you want to play with.

Is there some advantage to using OO here that I am missing?

Edit 1: After a bit of detective work, I have just seen that the author of the Perl API is also heavily involved in the maintenance and support of the Moose framework.

Edit 2: I have just seen this question which asks a similar thing from a slightly different angle. It's seems like my answer is actually "why would you want to add the complication in the first place?", especially given the info in edit 2 above.

POSSIBLE ANSWER

The API in question seems to be only using the Moose OO system in order to prevent namespace pollution.

This could also be done more than adequately by using Perl packages though, as @amon point out in the comment below, using the standard package mechanism can become cumbersome quite quickly. BTW A big thanks to for all the comments to help clarify what I was asking.

Answer 1

Every situation is diffferent, and whether you choose to use Moose or another object framework (or none at all) really comes down to what you're planning to do and what your requirements are.

There might not be any immediate advantage to writing the system in question with Moose, but consider these:

• You get free access to Moose's metaobject system, so you can interrogate the objects for useful information in a well-defined way
• You can extend the provided classes using Moose's inheritance system; so even if they don't use inheritance themselves, the framework is already in place for you to do so if needed
• You have peace-of-mind because you know the system was built on the most widely-deployed and well-tested object framework for Perl.
• People know Moose, meaning there is a higher probability of getting answers to questions if something breaks.

IOW, there is inherent value in using popular tools.

Answer 2

Not sure it's relevant to the API in question, but no-one seems to have mentioned data types yet - that's a big benefit of Moose or Moo, having easily defined and understood (and re-usable) type validation and coercion for attributes.