Why use Perl OO simply as a method of encapsulating data?

Question

I am trying to use the Perl API, which was written to use the Moose OO system, but there is absolutely no inheritance, aggregation or composition between objects.

And, except for one optional role for debugging, neither roles nor mixins are involved.

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

Why did you use Moose or OO as a simple encapsulation method instead of using a much simpler way to package your code in Perl modules?

To clarify, I am fully convinced of the many benefits of using Moose to run OO in Perl correctly and completely. I just don't understand why use OO at all as a simple encapsulation method? I am not a subjective argument in favor of or otherwise Perl OO. I hope that I am missing some advantage for using the OO paradigm here, that I just don't see atm.

This question contains an excellent sequence of data encapsulation points in Perl. Notabene I'm not talking about forced encapsulation , where the system stops you from searching, where you shouldn't, more about just exposing the methods in a package that manages the data you want to play with.

Is there any advantage in using OO here that I am missing?

Edit 1: After a little detective work, I just saw that the author of the Perl API is also strong participates in the maintenance and support of the Moose framework.

Edit 2: I just saw this question that asks a similar thing from a slightly different angle. It seems that my answer is actually “why do you want to add complication in the first place?”, Especially given the information in revision 2 above.

POSSIBLE ANSWER

The API in question apparently only uses the Moose OO system to prevent namespace pollution.

This can also be done more than enough using Perl packages, although, as noted in the @amon note, using the standard package mechanism can be quite cumbersome. BTW Thank you very much for all the comments that will help clarify what I asked.

Answer 1

Each situation is different, and regardless of whether you want to use Moose or another infrastructure of the object (or not at all), it really comes down to what you plan to do and what your requirements are.

There can be no immediate advantage to writing the system in question with Moose, but consider the following:

• You get free access to the Moose meta-object system so that you can interrogate objects for useful information in a certain way.
• You can extend the provided classes using the Moose inheritance system; therefore, even if they themselves do not use inheritance, the infrastructure is already created for you, if necessary.
• You have peace of mind because you know that the system was built on the most widely deployed and well-tested object infrastructure for Perl.
• People know Musa, which means that there is a high probability of getting answers to questions if something breaks.

IOW, it makes sense to use popular tools.

Answer 2

Not sure if this is relevant to the API in question, but no one seems to have mentioned data types — this is a big Moose or Moo advantage that easily defines and understands (and reuses) the type of validation and enforcement for attributes.