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

The way to hide variables and methods is not to document them. Programmers using a module are not expected to read the code, they're expected to read the documentation. Using undocumented features is always an At Your Own Risk activity.

Not quite - not documenting them is just one way to hide variables. Programmers may not be expected to read the code, but they don't always do as expected (do you?). I agree with your last statement

If you prefer to make things programmatically inaccessible, scoping is the built-in tool for that, though I don't think that proper methods (automatically passing self) can be made this way. I'm not sure why you don't consider closures a built-in way to hide things.

Ok, I can agree with you there. I've little experience with using scope to hide things from end users. I do consider closures a built-in way to hide things. I can see them in a scope sense being similar to private variables. However they seem to be more than that, and you have more rope to hang yourself with. I don't consider closures akin to the private/protected/public modifiers. That does not make it a bad thing, I just don't see it as being intended to provide that. I could be wrong, of course.

What I would say (overall) is that it makes placing an underscore before a private variable a secondary security measure. If a private variable is undocumented, that may well be the first line of defense, I'll grant you that. However, if a premise of using visual cues (or lack thereof) to alert a developer to the accessibility of an attribute or method has already been established, then it makes more sense to use the leading underscore in that case.

Replies are listed 'Best First'.
Re^6: I hate the leading underscores.
by Roy Johnson (Monsignor) on Feb 16, 2005 at 19:04 UTC
    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.
[reply]
      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.
[reply]
        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.
[reply]
      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.
[reply]
        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.

[reply]
        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.

        [download]
        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.
[reply]
[d/l]
[select]

In Section Meditations