Tye, first of all, thank you for replying. However, your reply is so much a discussion topic starter rather than a reply that I haven't much of an idea as to how to respond -- indeed it appears that I may not have been intended to respond to it, but rather somehow my post serves as an outlet for your venerable frustration.

My purpose is to encapsulate data, and provide methods which operate on said data. Some methods are straight accessors. Some do fancy things. Other objects are free to violate the data if they wish, if they dare, but none of my objects trust the data of other objects (Law of Demeter).

Your point stands, though. Perhaps my code is just masquerading behind a bare hashref, and I should cast aside the thin veneer of respectability. At the same time, these thinly disguised methods are useful... and present a uniform interface to polite users. Those methods which do more than simply parrot out a hash value stand with the accessors. I admit there is a potential for confusion between a "lvalue" accessor and a traditional method. I'll have to think about that as well.

As for inside-out objects, Perlmonks seemed to have made it abundantly clear that I-O Objects are easier to learn and less error-prone than using a hashref. Now Tye is telling me otherwise -- and I wouldn't get bothered by this except I know enough about Tye to take notice.

As far as a framework, well there are plenty to choose from, and I tend to go with the simplest solution which fits my purposes -- in this case, a source filter works fine. But that's a double-edged sword, because there's always the vague notion that someone may try to use my class (as unlikely as that sounds) for some purpose I wasn't expecting and my code breaks, feebly and uselessly, to the chagrin of this supposed-future-user. Principle of Least Surprise violated -- core dump -- my fault.