Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Naming convention for Object Variables

by lachoy (Parson)
on Aug 13, 2002 at 13:43 UTC ( #189785=note: print w/ replies, xml ) Need Help??


in reply to Naming convention for Object Variables

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 :-)

Chris
M-x auto-bs-mode


Comment on Re: Naming convention for Object Variables
Re: Naming convention for Object Variables
by Abigail-II (Bishop) on Aug 13, 2002 at 13:59 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.
    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.

    Abigail

      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.

      Chris
      M-x auto-bs-mode

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (10)
As of 2014-12-26 13:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls