Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: Why get() and set() accessor methods are evil

by pg (Canon)
on Nov 25, 2003 at 17:47 UTC ( #309981=note: print w/replies, xml ) Need Help??

in reply to Why get() and set() accessor methods are evil

I think:

  • Your statement is way too generalized, and looked at the situation basically in a black and white manner, when it is not;
  • The example you gave does not strengthen your conclusion.
  • (Also this is not an OO issue, but merely a Perl issue.)

But your example did make me think. Part of the problem your code showed is that it is not pure OO.

Ideally, modification of internal structure shall not cause interface change, but in this case, it caused. Is this caused by using of getter and setter? NO. Now if Perl becomes more OO,

  • Imaging you no longer return list, array or hash, instead you return an OO object, a collection (a collection of object, and the collection itself is also an object.)
  • list, array and hash are now OO objects
  • The OO objects represent list, array and hash all implement collection interface.

Now whatever you use internally, hash, array or list, the outsider world will see it in the same way (a collection that supports a given set of method, regardless how those method are IMPLEMENTED), and the setter, getter will stay the same.

The real problem is that your code is not pure OO, or Perl does not really support you to do it in that way.

But the defects showed by your code example does reminder people that, when you do OO design and coding in Perl, there are certain considerations special to Perl that you have to take into consideration.

  • Comment on Re: Why get() and set() accessor methods are evil

Replies are listed 'Best First'.
Re: Re: Why get() and set() accessor methods are evil
by hardburn (Abbot) on Nov 25, 2003 at 18:02 UTC

    (Also this is not an OO issue, but merely a Perl issue.)

    The example might have shown a problem specific to Perl, but the idea is applicable to any language. A Java API that returns an array of integers stored in an otherwise private field would be just as problematic.

    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      You are right, as Java also has primitive types.

      But on the other hand, in this case, I can choose to return, for example, an ArrayList of Integer. This is much less a problem to languages that have stronger OO support.


      Thanks BUU for the extension, tie was actually something I thought of. The idea of tie, actually holds some characteristics that OO interface provides.

        So why couldn't/wouldn't you do the exact same in perl? You could even do it transparently via tie, or you could do it overtly by creating the object. Seems fairly simple to me at least.
        package ArrayList; my $i; sub new{shift;return bless{[@_]=>shift};} sub iterate{return $_[0]->[$i++]}
        And so on and so forth.
Re: Re: Why get() and set() accessor methods are evil
by synistar (Pilgrim) on Nov 25, 2003 at 18:41 UTC

    Thanks pg. You explained it much more clearly than I did. The last link I gave advocates returning objects instead of primitive types. This very neatly avoids the problem and moves your program closer to the "everything is an object" ideal of languages like Smalltalk.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2022-08-18 07:40 GMT
Find Nodes?
    Voting Booth?

    No recent polls found