Re^4: tie for Perlish, encapsulated objects

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.

Comment on Re^4: tie for Perlish, encapsulated objects

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^5: tie for Perlish, encapsulated objects
by rir (Vicar) on Nov 28, 2005 at 21:22 UTC

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]