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

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.

Replies are listed 'Best First'.
Re^5: tie for Perlish, encapsulated objects
by perrin (Chancellor) on Nov 28, 2005 at 17:25 UTC
    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]
        Methods like get_/set_ do not necessarilly correspond to any actual member variable of an object. Making FETCH and STORE procedures that handle every possible method call would mean nested if statements or a dispatch table for all the exceptions, saying something like "if they tried to set the shnizzle property, go run some special method." Or worse, a bunch of in-line code for every exception in one gigantic method. It's far less practical than simply writing method calls in the first place.
[reply]

In Section Meditations