Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: Can I please have *simple* modules?

by Ovid (Cardinal)
on Nov 23, 2005 at 20:51 UTC ( #511243=note: print w/ replies, xml ) Need Help??


in reply to Re: Can I please have *simple* modules?
in thread Can I please have *simple* modules?

Why on earth would you want to retype that over and over again for every accessor/mutator?

Cheers,
Ovid

New address of my CGI Course.


Comment on Re^2: Can I please have *simple* modules?
Re^3: Can I please have *simple* modules?
by Perl Mouse (Chaplain) on Nov 23, 2005 at 21:04 UTC
    Huh? Retype? What primitive editor do you have?
    Perl --((8:>*

      No, I don't have to retype them. I have a reasonable editor and it can chunk out plenty of boilerplate code for me. Regardless, code duplication is code duplication. If you want to put a bunch of cut-n-paste boilerplate in your modules, that's fine. I just don't like to do it in my modules and I don't want to have to maintain it in other's modules. That means more code I or a maintenance programmer has to wade through to understand what's going on.

      Additionally, your method assumes a particular implementation (in this case, a blessed hashref). Not only does it make it easy for another programmer to violate encapsulation (even if it's only by accident), it also means that it's more work to switch your object to a blessed array ref or inside out objects.

      There's been plenty written about why duplicating even simple things like accessors/mutators is bad. Rather than want to do that, I just do this:

      use Class::BuildMethods qw/foo bar baz/;

      With that, I get three accessors/mutators without code duplication or reliance on the internals. Further, it's easy to extend them with default values or validation code. In short, by my writing this module once, my other code is cleaner and more flexible.

      Cheers,
      Ovid

      New address of my CGI Course.

        That means more code I or a maintenance programmer has to wade through to understand what's going on
        That's exactly why I like to spell out the accessors in my code. No other module to understand to know what the code is doing.
        Additionally, your method assumes a particular implementation (in this case, a blessed hashref)
        Uhm, no. Look again.
        Not only does it make it easy for another programmer to violate encapsulation (even if it's only by accident), it also means that it's more work to switch your object to a blessed array ref or inside out objects.
        Actually, the accessors are for inside-out objects, and if you want to switch to blessed array refs, you can leave the accessors I wrote them just they way they are. They will keep working.
        use Class::BuildMethods qw/foo bar baz/;

        With that, I get three accessors/mutators without code duplication or reliance on the internals.

        And a dependency on another module, who's internals are more complicated than one-liner accessors.

        I'd love to see the code of Class::BuildMethods that works independently of how the class using it is implemented, without denying the using class direct access to its data.

        Perl --((8:>*

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://511243]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2014-10-25 22:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (149 votes), past polls