Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re^6: MooseX obscure error and importance of Unit Testing (tools)

by chromatic (Archbishop)
on Sep 05, 2012 at 17:59 UTC ( #991902=note: print w/replies, xml ) Need Help??

in reply to Re^5: MooseX obscure error and importance of Unit Testing (tools)
in thread MooseX obscure error and importance of Unit Testing

Public accessors, for one.

I disagree slightly with tye that Moose forces them on you, but any OO code which spends a lot of time setting (or Larry help us all, even getting) attribute values from outside the object is questionable.

Good objects let you tell them what to do.

  • Comment on Re^6: MooseX obscure error and importance of Unit Testing (tools)

Replies are listed 'Best First'.
Re^7: MooseX obscure error and importance of Unit Testing (public attributes, generated accessors)
by tye (Sage) on Sep 06, 2012 at 14:26 UTC
    I disagree slightly with tye that Moose forces [public accessors] on you

    I find it entertaining that I must parse that as "chromatic believes that Moose forces public accessors upon you", since I don't believe that Moose does that and chromatic claims to disagree with me on that point. :)

    As I previously noted:

    Now, I'd be more convinced by the standard "don't blame the tool" arguments if I had argued that one shouldn't use Moose because it fails to prevent you from doing stupid things.

    Moose doesn't force you to do stupid things. I haven't even come close enough to such a claim as to have claimed that Moose should be faulted for failing to prevent you from doing stupid things.

    It is easy to see that you are quite free to do nothing at all, despite choosing to use Moose:

    package Uninteresting; use Moose(); # Why did we do this?? 1;

    (Untested, however, as I don't plan on waiting for hour(s) while Moose and all of its dependencies try to install.)

    But much more to the point, it is quite possible to fight against Moose and avoid violating encapsulation in your class design by not making your implementation details about what attributes to store in each object manifest in the public interface to your class.

    But doing that requires eschewing so much of the functionality of Moose that it starkly raises the question asked in the prior code comment.

    package Silly; use Moose; has 'foo' => ( is => 'bare', # no accessors init_arg => undef, # not exposed via constructor ); ...

    stvn himself says that the only benefit of using Moose that way is:

    What this buys you over doing it by hand is [...] proper constructor initialization for any subclasses (via BUILD).

    But inheritance (in Perl) is just anti-modular so claiming some benefit based on supporting inheritance doesn't actually demonstrate a benefit when trying to do good OO design.

    So that leaves us with using Moose to automatically generate "private accessors". Since private accessors have underscores at the front of their names, they don't actually leak implementation details into the public interface. Well, I half buy that argument.

    But even generated private accessors encourage poor class design. When you've got a generated accessor, you end up wanting to add a small bit of functionality to one of the accessors. So you end up defining a "data type" for that attribute and/or you declare a 'before' or 'after' wrapper around the method.

    And this leads to: "Your logic for a single class will be split apart into tons of tiny pieces where the order and interactions will become almost impossible to see, predict, adjust, and debug. But your code will look pretty. Just don't try to understand it on any sort of deep level (such as when you need to fix something)."

    To which stvn noted: "Nothing about Moose forces you into doing something as idiotic as you describe."

    So, yes, you don't have to use generated private accessors with Moose since the only way to adjust/extend them is "idiotic" design.

    So, the bottom line is that using Moose but not in any of the ways that lead to non-modular or idiotic design also means that Moose offers no benefits. So there is no point using it that way.

    And having repeatedly had to deal with the pain of the non-modular design that takes great discipline to avoid slipping into once you establish a practice of using a tool that makes generating accessors easy or encourages the use of inheritance to partially re-use code (despite working with a group of very smart and capable Perl developers), I very much don't want to revisit that pain.

    And the pain of fragmented code from "idiotic" design from when you've established a practice of using a tool that encourages generated accessors that you customize with different types of wrappers ("datatype", "before", "after", etc.) was so acute that having experienced when that becomes painful only a few times was still enough to make me quite eager to avoid it.

    So, yes, I find using Moose is very likely to lead to painful situations caused by poor class design in the long run. But only if you actually use any of the features that Moose provides. So, indeed, "Nothing about Moose forces you into doing" this. (:

    - tye        

      So, the bottom line is that using Moose but not in any of the ways that lead to non-modular or idiotic design also means that Moose offers no benefits.

      But, you're forgetting the introspection.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://991902]
[Discipulus]: i need some converter to have directly an OVF format directly: at the moment i'm trying with vmware converter standalone
[Lady_Aleena]: I don't know what to tell you. I can barely get my Linux machine to do things I want.
[Discipulus]: if DE or WM means desktop env and win manager.. no, not an option
[Lady_Aleena]: That's what they mean, at least to me. 8)
[Discipulus]: in the first attempt i failed, with an not usable v-machine.. ;=)
[Discipulus]: but then discovered a registry trick to do before the physical2virtual migration
[Lady_Aleena]: Sounds like a headache.
[Discipulus]: a bit shaggy.. every atttempt is ~4hours to virtualize and 1-2hours to kick the big file to boot..

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2017-05-22 18:45 GMT
Find Nodes?
    Voting Booth?