http://qs321.pair.com?node_id=309981


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

I think:

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,

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.

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.

      Update:

      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.