Pablo Fischer wrote:
Thanks!
After sending my question I found in a website the topic of 'private' methods,
and shows code like this:
my $method_name = sub { my $this = shift;
_blablabla_ };
And to access it :
$this->$method_name("Arg1");
Now, this it really works for 'private' methods?
This is the standard Perl way to create private methods, yes. The subroutine is only available within the scope of the my variable, generally your module.
Perl has no private methods. Only polite conventions concerning which methods
should be called from outside the pm file.
Uh, did you read the question? :) That looks like a pretty text book perfect private method to me, but please correct me if I'm wrong.
I believe what Joseph meant to say is the Perl doesn't have a 'private' keyword, like many OO languages. However, Perl generally gives you the tools to do what needs to be done, just as you show above. I disagree that Perl doesn't have private methods.
The real meat of Joseph's message is that most OO Perl programmers feel that what you show above is seldom called for. While most languages give you the tools to lock things down as tight as possible, Perl prefers the "If you push the big red button marked 'Do Not Touch!', don't come crying to us" philosophy. Generally, saying 'Hands Off' works in Perl land. If they mess with it after that, they knew what they were getting into and deserve whatever pain they get.
There are even some instances where security hurts users. By way of example, Perl's OO system is known to have a good bit of overhead and thus be a little on the slow side of execution. Accessors, while a great OO principal, generally show off this slowdown, in a bad light. In Perl though, what you usually have as your object reference is a blessed hash. Is there really a good reason you can do your own hash lookup? For some objects, sure there is, but a lot of the time I think read-only hash access of an object's data is fine, especially when speed really counts. Heck, document this in your module and list is as a feature, when you can. Instead of straight jacketing Perl into Good OO Behavior, use Perlisms to your advantage.
Of course, just to be thorough I need to say, there are definitely times when security IS called for. Most Perl guys don't think they're as often as the Encapsulation Fanatics would have you believe, but they definitely exist. As the programmer, it's your job to determine when those situations arise and employ the proper amount of paranoia. With great power comes great responsibility, as they say. Make good choices.
One way to communicate this is simply to document only public methods using the emedded donumentation format, and use standard comments for any necessary explanation of internal methods.
Another popular convention is to start any Perl identifier (variable name, subroutine name, etc.) with a _ when you want to tell users it's important stuff only you need to handle. Many modules follow this and some will even help you enforce it, when you do need the security.
James Gray
Joseph
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
