in reply to Examples fo Where "our" is really needed

AFIAK the only reason to use our() instead of use vars is that it's cleaner to restrict access global variable to some limited scope(s) where you intend to use them: use vars opens up the access till the end of file the package.

In other words - the scoping of our() is the only difference compared to use vars.

my is different in that lexicals aren't coupled to a package and therefore need extra work if you want access to them from another file.

update:

As for the performance of our() vs vars() vs my () - AFAIK lexicals are always faster than globals - provided you have direct access to them - since package globals require a hashtable lookup and lexicals are in an array of which the index is computed at compile time.

My conclusion:

You are probably right that most uses of package variables are gratuitous and could be replaced with lexicals without any trouble.

However, if you need access to variables from another file, or are interfacing with XS code, and you're sure that you really only need one instance of that specific variable, a package variable can be easier and more efficient than a lexical.

  • Comment on Re: Examples fo Where "our" is really needed

Replies are listed 'Best First'.
Re^2: Examples fo Where "our" is really needed
by dave_the_m (Monsignor) on May 05, 2005 at 01:17 UTC
    lexicals are always faster than globals - provided you have direct access to them - since package globals require a hashtable lookup
    package variables do not require a hash table lookup; each relevant op contains a pointer to the typeglob (or in the case of ithread builds, an index into the pad which contains the typeglob). It's still slightly slower than lexicals since a few more pointers have to be followed.

    Dave.