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

There should be a difference between calling methods and using members, IMO. They're different. But this is a meditation about the fact that a hash can be API rather than an implementation detail. I did not intend it to be taken as yet another One True Way to implement objects, and I'm sorry that, judging from the replies, I seem to have given that impression.
Caution: Contents may have been coded under pressure.
  • Comment on Re^2: tie for Perlish, encapsulated objects

Replies are listed 'Best First'.
Re^3: tie for Perlish, encapsulated objects
by rir (Vicar) on Nov 24, 2005 at 22:29 UTC
    There should be a difference between calling methods and using members

    Why do you say that? I have been going towards the opposite conclusion and say that a primary purpose of getters and setters and such is to hide or homogenize the distinction.

    Be well,
    rir

[reply]
      I think that we have taken two paths away from OO design. I will dub yours "method-oriented design", and will call mine "member-oriented design". See The Accessor Heresy for what I consider to be the Object-Oriented approach to this matter, and contrast that with our philosophies here.

      The "method-oriented" approach is a performance-driven departure from real OO design. It saves on creating bunches of objects for the accessible members. That approach rankled, although I didn't understand clearly why. It had something to do with the demotion of members from their rightful place as objects. My "member-oriented" viewpoint was a rather tortured way of making members into objects whose object nature Perl hides; it made them more special than they needed to be.

      Caution: Contents may have been coded under pressure.
[reply]
        My view had little to do with OO design per se.

        If we have a namespace and export some thing via some interface. If we allow the client to know if the thing is a variable or a routine then we are exposing the implementation of our namespace.

        From a client perspective, the distinction between variable and routine is artificial and is purely an artifact of implemention (of the interface).

        Be well,
        rir

[reply]
Re^3: tie for Perlish, encapsulated objects
by perrin (Chancellor) on Nov 28, 2005 at 04:39 UTC
    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.
[reply]
      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]

In Section Meditations