in reply to Re^5: I hate the leading underscores.
in thread I hate the leading underscores.

Not quite - not documenting them is just one way to hide variables.
It is the official Perl way, as envisioned by Larry Wall. (I should have said "members" rather than "variables". Hiding variables is done by scoping.) Any other technique used to hide private methods and members constitutes an attempt to write C++ (or some other language) in Perl.
it makes placing an underscore before a private variable a secondary security measure
It's really just a flag to help the module author (and any developer with prying eyes) keep things straight. Nothing more. I agree that it's a good convention.

Caution: Contents may have been coded under pressure.

Replies are listed 'Best First'.
Re^7: I hate the leading underscores.
by TimToady (Parson) on Feb 16, 2005 at 20:31 UTC
    It is the official Perl way, as envisioned by Larry Wall.
    Larry Wall seems to have had a slight vision adjustment on this subject. See A12 and S12 for details.
      Well, yeah, but that's Perl 6. He has had many vision adjustments in Perl 6 relative to Perl 5. I suppose I could have said "constitutes an effort to write Perl 6 in Perl 5" above.

      Caution: Contents may have been coded under pressure.
Re^7: I hate the leading underscores.
by RazorbladeBidet (Friar) on Feb 16, 2005 at 19:13 UTC
    It is the official Perl way, as envisioned by Larry Wall. (I should have said "members" rather than "variables". Hiding variables is done by scoping.) Any other technique used to hide private methods and members constitutes an attempt to write C++ (or some other language) in Perl.


    Do you have a link to that? Also, while I agree that Mr. Wall has done some amazing things, people can be different. Using other techniques would not constitute the attempt to write another language in Perl, it would be an attempt to write OO, which is precisely what Perl is trying to emulate with classes.

    It really does just come down to a matter of preference, and the leading underscore really isn't the problem, it's the incomplete OO support. Although please note I have not delved in depth into Perl's OO support beyond simple class constructs, so please do correct me if I am wrong) People have issues in Java with underscores all the time.
      The famous "shotgun quote" appears in perlmodlib:
      Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would pre- fer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

      The module and its user have a contract, part of which is common law, and part of which is "written". Part of the common law contract is that a module doesn't pollute any namespace it wasn't asked to. The written contract for the module (A.K.A. documentation) may make other provisions. But then you know when you "use RedefineTheWorld" that you're redefining the world and willing to take the consequences.

      Do you have a link to that?
      In perldoc perlmod, Larry laid out the conceptual basis of OO for Perl.
      Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.
      it's the incomplete OO support
      It is a misconception that strong data hiding is integral to OO, just as it is a misconception that strong data typing is integral to programming languages. The language is to serve the programmer, not to handcuff him.

      Calling an undocumented method is not an easy mistake to make. If some programmer does that, it's most likely intentional. The programmer is violating OO programming guidelines, it is not the language's fault for letting him do something that isn't OO.

      That said, here is what I think is a kind of clever way to hide private methods. Wow, was that not a good idea. There shouldn't be private methods, just private subs. And the easy way to hide them is to make them lexical coderefs.


      Caution: Contents may have been coded under pressure.