If it hurts... Other than "because the cool kids are doing it", why are you subjecting yourself to the complexity of the bizarreness that is "inside-out objects"? ...especially without using a framework that takes care of the destructor complications and the need to write a bunch of accessors (which also results in poor OO design, IME, since you end up making public accessors for getting at the raw attributes of your objects instead of separating your design between the attributes you need to store and the interfaces you need to provide).

I find it so bizarre that it has become the default practice to jump through convoluted hoops to provide draconian isolation of your attributes into lexical variables and then go roll an all-access accessor for each. Shouldn't one feel foolish after doing that?

I'd rather have compile-time catching of mispelling of attribute names (instead of run-time catching). But more importantly, I'd rather have a distinction between the internal interface that implements the object and the external interface that defines how it is meant to be used. That's a big part of the point of OO.

I've heard people argue that you should use accessor methods inside a class in order to access your attributes because the layer of abstraction may prove useful at some future date. But since Perl doesn't have /private/ methods, this effectively breaks down the distinction between internal representation and external interface. And that leads to bad interface design (why spend time designing a proper interface when your default "add this attribute" rote already produces a method that anyone can use to set things however they want?).

We've gotten rid of the evil "it is just a hash under the covers" and replaced it with "what it is under the covers is very securely protected from your inspection, but it works exactly like a hash except with accessor names instead of key names". "Just a hash" was so evil that we had to destroy it and bury the replacement and then produce interfaces where the "just a hash" nature is in your face rather than under the covers.

In trying to hide the hash, we've produced something much more complicated that exposes even more hashiness.

So, no, I don't think adding a source filter is a net improvement on that situation. :)

- tye        

In reply to Re: RFC: The Poor Man's Accessor Filter (upside-down) by tye
in thread RFC: The Poor Man's Accessor Filter by rje

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.