Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Naming convention for Object Variables

by Basilides (Friar)
on Aug 13, 2002 at 13:32 UTC ( #189781=perlquestion: print w/ replies, xml ) Need Help??
Basilides has asked for the wisdom of the Perl Monks concerning the following question:

I'm still not quite clear on the correct naming convention for object variables, even after frankus's suggestion that I RTFM ;-) I'd really like to get this straight as I've got a big project to hand in at college soon, & I don't want it looking too mad. (I've thought about this, and I don't think it counts as homework trolling--see my next node for that!)

frankus notes that the underbar convention--$self->{_words}--should be used only for "private properties" and quotes perltoot:

Occasionally you'll see method names beginning or ending with an underscore or two. This marking is a convention indicating that the methods are private to that class alone and sometimes to its closest acquaintances, its immediate subclasses. But this distinction is not enforced by Perl itself. It's up to the programmer to behave.
But I'm still a bit confused. My variables are private properties, I guess, in that they can't be directly accessed by other objects. They're not methods tho'.

Basically, I've got a pretty vast project, where all private object variables have the underscore in their name. If this is just plain wrong, I'll change them all. If it's not, well that's a relief.


Comment on Naming convention for Object Variables
Select or Download Code
Replies are listed 'Best First'.
Re: Naming convention for Object Variables
by Joost (Canon) on Aug 13, 2002 at 13:52 UTC
    Put an underscore in front of private methods. Personally I never put an underscore in front of private properties, because I think that all public properties should have accessor methods, or better yet, everything that an object should do should be available using methods.

    There are a couple of advantages to doing it that way:

    • Methods have a nice inheritance mechanism, properties don't.
    • Method implementations can be changed, but properties have to stay the same to be compatible.
    • It's usually easier to think up an interface using methods, and then worry about implementing them. In my experience, this makes for a much more useful object design too.

    By the way, it is very likely that your 'private' properties are accessible by other code. Don't worry about it, just don't document it.

    -- Joost downtime n. The period during which a system is error-free and immune from user input.
Re: Naming convention for Object Variables
by fuzzyping (Chaplain) on Aug 13, 2002 at 13:55 UTC
    The convention you're referring to is suggested for the naming of private attributes and methods, not the objects themselves. This is, as you've alluded to, to designate that these shouldn't be accessed directly by the caller; rather, they should be manipulated indirectly through the available public methods.

    However, you're actually inquiring as to the naming convention for the object itself, not the attributes used to describe or the methods used to access it. Based on my experience, there is no formal convention... just common sense. An object name should reflect the object itself... perhaps a combination of it's relevance to the class and it's uniqueness (compared to other similar objects). Examples:

    my $cgi = CGI->new; my $template-adduser = HTML::Template->new(filename => 'new_user_form. +tmpl'); my $template-deluser = HTML::Template->new(filename => 'del_user_form. +tmpl');
    As always... UYBJ! (Use Your Best Judgment)

Re: Naming convention for Object Variables
by lachoy (Parson) on Aug 13, 2002 at 13:43 UTC

    The best thing to do is create a accessor and mutator method (or one combined method as seen often in Perl modules) for each of your properties. Users of your objects can only use these to access the property, then you're able to name them whatever you like.

    Using a module to automate this is highly recommended. I'm partial to Class::Accessor just because it's focused and simple, but Class::MethodMaker does this and much more. If you'd like to learn, do it yourself using AUTOLOAD :-)

    M-x auto-bs-mode

      The best thing to do is create a accessor and mutator method (or one combined method as seen often in Perl modules) for each of your properties. Users of your objects can only use these to access the property, then you're able to name them whatever you like.
      Eh, no. The root of all evil is that there's just one instance variable per object, and that all classes need to stuff their properties in it somehow.

      Sure, you can make accessors:

      sub oogle { my $self = shift; $self -> {oogle} = shift; # Mark it as very, very, very, do not touch at all private: $self -> {_________________furble} ++; }
      But if 10 levels up in the inheritance tree there is an accessor
      sub habar { my $self = shift; $self -> {_________________furble} = 0; }
      You are still in deep shit. No matter how many underscores you use.

      Perls OO model was broken when it was designed. As I said at YAPC It sucks (to which Larry replied "I'm working on it"). Using Perl OO is no fun at all.

      Luckely, there is a way to make your properties private while not losing the ability to do inheritance, or pay a costly runtime fee. Use Inside Out Object. Reverse the traditional roles of objects and properties. Let the properties be hashes, and the objects the keys:

      package My::Package { my %furble; my %oogle; sub oogle { my $self = shift; $oogle {$self} = shift; $furble {$self} ++; } }
      And how your inherited classes are implemented no longer matters. You'll never interfere with their properties, regardless what kind of conventions they use.


        Root of all evil -- wow! I don't think I've ever done anything that can be described as that. :-)

        The poster seemed to be at a level where discussing this sort of reverse composition would be even more confusing. If I'm doing any sort of subclassing I generally use straightforward composition/delegation stored in a key derived from my class. But I entirely agree that these sorts of ugly hacks are necessary illustrates a fundamental flaw.

        M-x auto-bs-mode

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://189781]
Approved by shadox
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (2)
As of 2015-11-27 04:36 GMT
Find Nodes?
    Voting Booth?

    What would be the most significant thing to happen if a rope (or wire) tied the Earth and the Moon together?

    Results (718 votes), past polls