•Re: REALLY Private Methods in perl: Is Perl Flexible enough to be made Inflexible?

[merlyn]

Yes. There are quite a few variations of "privateness" documented in theDamian's excellent Object Oriented Perl. You can check the file and line number of caller, for example.

However, the moment you do that, I would not want to maintain your code. Every attempt I've seen at privacy has made the code more unmaintainable.

Just name your "private" methods with a leading underscore, and put "do not call outside of this class" in a comment. People will get the idea, and they deserve what they get when they violate it. Why is that so hard to understand?

-- Randal L. Schwartz, Perl hacker

[penguin]

I hear ya dude :) However, you never know when management or a client might ask you to do the ridiculous ;)

[merlyn]

However, you never know when management or a client might ask you to do the ridiculous ;)

And it's your job to explain why not to do that.

Don't cave. If you do, you end up increasing the cost of the software overall. It's bad ethics.

If your boss/client is so pigheaded that they won't see your well-reasoned point, quit. Get another job.

-- Randal L. Schwartz, Perl hacker

[sauoq]

If your boss/client is so pigheaded that they won't see your well-reasoned point, quit. Get another job.

This advice isn't very realistic or helpful. It's easier said than done especially given the current market conditions. Besides, if everyone followed it, we'd all be working for the same two or three companies... and tilly would probably still walk among us.

-sauoq
"My two cents aren't worth a dime.";

[Anonymous Monk]

Wow dude!! That was pretty loaded. And easier said then done ;) It's ALWAYS good to know all your alternatives.

A well reasoned point, incidentally, might be a long-lived software project with a large hierarchy of objects and a whole bunch of developers. It's a sad truth that some developers don't really care about good programming practices. Do you really want sloppy coders violating your well-designed system by making frequent calls to subroutines with underscores?

Bad coding practices sneak into the best of companies during crunch-times. And if it's the client's developers who are being sloppy, well...you don't have to be busness-trained to realize that dumping a paying client over the love of perl isn't in a company's best interest. Rather let them learn by example over time with gentil and wise encouragement.

BTW, did you go to Mac? We may have a mutual friend :)

[Anonymous Monk]

"If your boss/client is so pigheaded that they won't see your well-reasoned point, quit. Get another job." - while everything else is unworkable the way you say, unfortunately this also does not work (round here, anyway). In fact, you can't even get another job, while at the same time caving in makes you less marketable anyway. Pointy haired rules OK! PML.