For me, the important distinction is accidental vs. intentional. Steps to discourage intentional misuse are mostly futile and are more than a waste, IMO. I usually find myself intentionally violating such restrictions because the author of the module lacked good design skills and making it a pain for me to overcome your stupid mistakes isn't a worth-while feature. And I don't want to make it a pain for other people to overcome my stupid mistakes.

Trapping accidenal misuse can often be a good thing. Code reviews are a Good Thing™, but I don't want to rely on code reviews for enforcing complex restrictions when those can be trapped more reliably in an automated fashion.

But I seriously doubt I'd make use of such a complex (my first impression) solution as proposed above. I'd need to see what real or likely accidental misuses this is intended to trap. My first impression of the above solution is that is appears broken anyway [it seems like it should be seeing if (caller(2)'s package)->can(caller(1)'s method name)]. So I probably don't understand the point of it.

And I doubt I'd use inheritance to get this helper subroutine available to every class that wants to define protected subs. I'd probably just export it instead (into the "implementation" package that method code is compiled under so that I don't polute the object method namespace with things that aren't meant to be called as methods by users of my objects).

As my impression of the idea of this sinks in, I start to think that I might use something similar to this in some cases. Removing inheritance and the polution of the namespace of object methods from its implementation makes me more comfortable with it. I'm not sure that the way @ISA is searched using can() is the best approach here. Then there is the complication that my methods are usually compiled into a package other than the one that objects get blessed into and I wouldn't want this check to incorrectly fire because of that. I'd have to do some digging on which packages are returned in which values from caller and some thinking about what really is supposed to be enforced here. No, I suspect that my OO "best practices" would break this code.

I also suspect that stepping back and looking at the specific problem may lead to a solution other than "protected methods".

- tye        

In reply to Re^2: Private and Protected class methods (accidental) by tye
in thread Private and Protected class methods by radiantmatrix

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.