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

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.
  • Comment on Re^5: tie for Perlish, encapsulated objects

Replies are listed 'Best First'.
Re^6: tie for Perlish, encapsulated objects
by Roy Johnson (Monsignor) on Nov 28, 2005 at 17:46 UTC
    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]
        You have clearly not understood anything I've written.
        Methods like get_/set_ do not necessarilly correspond to any actual member variable of an object
        I'm talking about an API. That was the main thrust of my original post. Actual member variables are supposed to be hidden, and they are hidden equally well by my method or yours.
        Making FETCH and STORE procedures that handle every possible method call would mean
        I didn't suggest that they should handle every possible method call. They are specifically for simple accessors. Any other methods would be written just as before.
        Caution: Contents may have been coded under pressure.
[reply]

In Section Meditations