in reply to tie for Perlish, encapsulated objects

This results in an inconsistent interface combining hash access: 
    $obj->{field}

[download]
with object methods: 
    $obj->action()

[download]
Remember: There's always one more bug.

Replies are listed 'Best First'.
Re^2: tie for Perlish, encapsulated objects
by Roy Johnson (Monsignor) on Nov 24, 2005 at 16:22 UTC
    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.
[reply]
      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]
      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]

In Section Meditations