in reply to Re^2: tie for Perlish, encapsulated objects
in thread tie for Perlish, encapsulated objects

Most OO design writing I've seen says that accessor methods are supposed to hide the existence of member variables, in case the implementation of the class changes.
  • Comment on Re^3: tie for Perlish, encapsulated objects

Replies are listed 'Best First'.
Re^4: tie for Perlish, encapsulated objects
by Roy Johnson (Monsignor) on Nov 28, 2005 at 16:29 UTC
    The point of the meditation was that the implementation can change; tie makes the hash merely an API.
    Caution: Contents may have been coded under pressure.
[reply]
[d/l]
      If attribute accessors look different from method calls, and you change something that makes what used to be an accessor into a method call (e.g. it now has to set a property of some other contained object instead), the code using this API would have to change. That's why accessors should not look different from other methods.
[reply]
        But accessors do look different from other methods. They are generally spelled getDoohickey and setDoohickey. And if you "change it into a method call", it still looks like an accessor unless you change the API. Similarly, ->{Doohickey} looks like an accessor; if you "change it into a method call", you're only changing the FETCH and STORE procedures behind the scenes. It still looks like an accessor unless you change the API.
        Caution: Contents may have been coded under pressure.
[reply]
[d/l]
[select]

In Section Meditations