Re^3: tie for Perlish, encapsulated objects

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

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:49 UTC
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]
Re^5: tie for Perlish, encapsulated objects by rir (Vicar) on Nov 28, 2005 at 21:22 UTC
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]