Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^2: coding rules

by ihb (Deacon)
on Jun 12, 2005 at 00:16 UTC ( #465873=note: print w/replies, xml ) Need Help??


in reply to Re: coding rules
in thread coding rules

Yes, it is a pain to fully qualify package variables, but that's the point: their cumbersome nomenclature indicates that they should be used as little as possible.

... and once you change the package name you'll almost definately create a bug. This might not apply to you as you're mostly a script author, but as a module author this just isn't a good advice.

Why should package variables be more cumbersome and less used that file-scoped lexicals?

Btw, why do you feel a need to typographically distinguish file-scoped lexicals from package variables? During development I sometimes go from file-scoped lexical to package variable and back to file-scoped lexical again, and in my module I often don't care what nature the variable is since I inside the file usually just have one package. (If I have two packages I usually put them in different lexical scopes, and put any shared variable at file scope. Keeping track of those very few variables isn't hard, especially since they're the first thing you see when you open the file.)

I'm interested in what made you choose this style with regards to package variables.

ihb

See perltoc if you don't know which perldoc to read!

Replies are listed 'Best First'.
Re^3: coding rules
by tlm (Prior) on Jun 12, 2005 at 13:28 UTC

    I'm interested in what made you choose this style with regards to package variables.

    The same principle that motivates the entire thread: to make different things look different. Full qualification seems to me like the natural way to make package variables stand out as such.

    Package variables are the worst, because their scope transcends a single file.

    I'm less worried about package name changes (my editor can do search and replace fine) than about typos (e.g. assigning to $Typo::foo). If I were to drop this coding practice, this would be the reason. But, anyway, I already refer to all package variables, even those from modules I did not write, using fully qualified names, because I think it makes the code clearer. So this particular practice of mine is an extension of a more general one.

    the lowliest monk

      Package variables are the worst, because their scope transcends a single file.

      How are package variables worse than file-scoped lexicals? If it's because it allows people to mess with parts of your code that you didn't intend, then why use a package variable instead of a file-scoped lexical? (Yes, there are a few rare legitimate reasons.) If you have a legitimate reason for using it but it's not a part of the interface, is it bad because you feel a need to "protect" your variables from users? (If that's the case I guess regular subroutines are bad too.) If you have it like a package variable because it's a part of the interface, then it's not evil. Those are the cases I can think of where I'd use package variables in modules, and I can't figure out why you think package variable are "the worst". Can you elaborate?

      ihb

      See perltoc if you don't know which perldoc to read!

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (2)
As of 2020-10-24 17:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (246 votes). Check out past polls.

    Notices?