Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^3: I hate the leading underscores.

by RazorbladeBidet (Friar)
on Feb 16, 2005 at 13:28 UTC ( [id://431561]=note: print w/replies, xml ) Need Help??


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

Agreed. Private methods/variables should have no reason to be called outside a class. If necessary, simply make a public accessor that calls that private method/variable.

I personally use underscores because it is helpful from a visual standpoint. Especially when there are no built-in security measures in place to hide variables and methods (not include closures, but that's not what I'd consider a "built-in" way to hide things, no offense to closures, of course).

Even still, coming from Java, I used them there. You simply get used to it, and while I agree it is not the prettiest thing in the world, I've seen worse :)

Replies are listed 'Best First'.
Re^4: I hate the leading underscores.
by Joost (Canon) on Feb 16, 2005 at 20:09 UTC
    Just to give a slight hint at how you can use closures to hide methods:
    #!/usr/bin/perl -w use strict; package Foo; { # private my $set_a = sub { my $self = shift; $self->{a} = shift; }; # public sub a { my $self = shift; return $self->{a}; } # public sub new { my $self = bless {},shift; $self->$set_a('abcdef'); return $self; } } package main; my $foo = Foo->new; print $foo->a();
    It is a pretty secure and not too hard way to hide private methods, but I've never used it in production code, because I happen to agree with the philosophy that undocumented methods are private. It does have the advantage of not polluting namespaces with private methods, though.

Re^4: I hate the leading underscores.
by seattlejohn (Deacon) on Feb 17, 2005 at 02:24 UTC
    Private methods/variables should have no reason to be called outside a class.

    How about whitebox unit testing? I do this all the time.

            $perlmonks{seattlejohn} = 'John Clyman';

      Good point - looks like that comes up in JUnit testing as well:

      JUnit

      How do they solve it? Reflection :) Pretty much a hack around it, I suppose.
Re^4: I hate the leading underscores.
by Mutant (Priest) on Feb 16, 2005 at 16:25 UTC
    Agreed. Private methods/variables should have no reason to be called outside a class. If necessary, simply make a public accessor that calls that private method/variable.

    What if you don't have access to the original source code? Usually you do in Perl, but it's not always convenient to modify it. You're then at the mercy of someone else's design decisions.

    You could have a perfectly legitimate reason for calling a method that someone else thought you wouldn't or shouldn't. The problem with a strict OO design is that it assumes the original design is perfect.

    I'm not saying we should always call private methods (otherwise there'd be no need to indicate them with a leading underscore), but it's nice to have the option.

      Just call the method if that pleases you. Noone is stopping you from calling an undocumented method. Just don't be surprised that after an upgrade, the method is no longer there, or causes your system to send out spam.

      That's what private means. It means the author/maintainer keeps the rights to modify it without notice. I don't see the difference between calling a private method or fiddling with attributes directly. It's great as long as it works. But you've voided your warranty. If you do it with my modules, you don't get support, and you don't get sympathy if your program breaks.

      What if you don't have access to the original source code? Usually you do in Perl, but it's not always convenient to modify it. You're then at the mercy of someone else's design decisions.

      That's usually why you'd need protected elements. So derived classes can access them. But I believe there are cases where you should be mindful of changing access to private information. It's private for a reason.
Re^4: I hate the leading underscores.
by Roy Johnson (Monsignor) on Feb 16, 2005 at 18:18 UTC
    there are no built-in security measures in place to hide variables and methods
    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.

    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.

    More on this topic in Private Methods Meditation.


    Caution: Contents may have been coded under pressure.
      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.
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://431561]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2024-03-29 05:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found