4

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.

Community
  • 1
  • 1
Rob Wells
  • 36,220
  • 13
  • 81
  • 146
  • 2
    this question would be much less likely to be closed as not constructive if it were rephrased as "when would you use an OO framework such as Moose and when would you not; what are the pros and cons for a simple object"? – ysth Jun 11 '13 at 14:45
  • 1
    @ysth I agree for the question you ask, but that is not what I am (trying to?) ask. The advantages of using an OO framework in Perl, and especially Moose, are well-known. I am after why you would use OO at all just for data encapsulation when Perl modules give you that anyway. – Rob Wells Jun 11 '13 at 14:52
  • 3
    Maybe the reason why everybody mis-reads your question is that they (just as me) find it hard to see how a non-OO perl module will give you data encapsulation. Can you provide an example of what we are talking about here? – innaM Jun 11 '13 at 15:02
  • cheers @innaM - i've just added another clarification – Rob Wells Jun 11 '13 at 15:29
  • Now I'm even more confused. The question you now linked to and all its answers use some form or other of Perl-OO. – innaM Jun 11 '13 at 16:17
  • 2
    My understanding of the question is "If your objects are nothing more than a blessed reference - no inheritance, no methods other than simple accessors, no roles, etc. - then what's the point of making them objects instead of just using a plain reference?" Is that reasonably accurate, @Rob Wells? – Dave Sherohman Jun 11 '13 at 16:27
  • @DaveSherohman that's almost it. There aren't any simple accessor functions either! – Rob Wells Jun 11 '13 at 16:39
  • 1
    In that case, OOP provides namespacing. Multiple unrelated classes can have methods with the same name. If all functions were imported into the current package, there would be conflicts (of course, one could always use the fully qualified name, but that can get tiresome). In a sense, every Perl package is a singleton object, so all issues with singletons apply here (global state, testability!). Using proper objects avoids this. – amon Jun 11 '13 at 16:45
  • @innaM The question itself that I linked to shows an example of using a Perl package to mimic an OO object **without** using an OO framework. And the answers referring to Conway's "inside-out" objects is also not really an OO framework. Are you trying to enforce being pedantic about enforcing immutable private data, i.e. a user of the object can only change those data members that the package designer wants? I think that that is an entireky different question and not really related to what I am trying to ask. – Rob Wells Jun 11 '13 at 16:53
  • if there aren't all these data OO things and yet there is data encapsulation, show an example of what you mean...cause so far I am clueless. are there in fact instances of the class, with per instance data attached? – ysth Jun 11 '13 at 18:26
  • @amon I think that you've hit the nail on the head. The use of the Moose system in the API I refer to seems to only be being used to prevent namespace pollution which could also be done more than adequately by using Perl packages. Though, as you point out, this can become cumbersome quite quickly. – Rob Wells Jun 11 '13 at 19:16
  • Can you just name the API? (I presume it's publicly available). This is a bit vague without seeing the code. – plusplus Jun 12 '13 at 08:38
  • @plusplus hi, it is "publicly" available via GitHub but I'm not sure how public it is intended to be atm. It is a preliminary v2 version of a FOSS API that has been around for a while. . I will provide a link to the API when I clarify if that is ok. – Rob Wells Jun 12 '13 at 13:19

2 Answers2

2

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.

friedo
  • 65,762
  • 16
  • 114
  • 184
  • I totally agree with you about the advantages of Moose for OO. What I don't see is why use OO at all simply as a data encapsulation technique. – Rob Wells Jun 11 '13 at 14:35
  • 1
    @RobWells: can you clarify the question? until this comment about data, I thought you were just talking about code encapsulation (e.g. a module that only instantiates a singleton), largely because of your "instead of using the far simpler technique of packaging the code into Perl modules" – ysth Jun 11 '13 at 14:42
  • @ysth hopefully clarified now. btw code encapsulation comes into this as well because the member functions of the Perl module are also a part of the encapsulation. – Rob Wells Jun 11 '13 at 15:31
1

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.

plusplus
  • 1,992
  • 15
  • 22