in reply to Re^8: the "our" declaration ?!!
in thread the "our" declaration ?!!

"our" is one of the best improvements in perl, because one has not to fiddle around anymore with different scoping rules for "my" and "vars" and allows consistent declarations! That's orthogonality (almost) at it's best! Unfortunately the features are ignored by the wide public, thinking it's just a a new name for an old mechanism.

Anyway there are some traps when our is used with special vars, for instance something like  our $\="\n"; will make B::Deparse fail ...

lanx:~$ perl -MO=Deparse perl/myour.pl While deparsing perl/myour.pl near line 3, Unexpected our($\) CHECK failed--call queue aborted. lanx@:~$ perl -version This is perl, v5.8.8 ...

nice for obfuscation ; )

> In any case this is an example of why it is better to have a precise understanding of how features work rather than having a vague impression that is going to mostly work, most of the time.

FULL ACK! Especially because really understanding "our" implies really understanding "my".

Cheers Rolf

Replies are listed 'Best First'.
Re^10: the "our" declaration ?!! (special vars)
by tilly (Archbishop) on Jan 21, 2009 at 16:20 UTC
    I respectfully disagree in the strongest of terms on the value of our. See Why is 'our' good? for an explanation of why.

    Incidentally our and my have slightly different rules. One is allowed to use local with our variables but not my ones. Of course that is due to an artificial restriction on my, but still it is a difference.

      I can understand that you are used to vars, and normally I preferre lexicals to packvars.

      Actually I don't know if I really understood "vars" scoping rules, so I "lazily" stick on "our".

      That's maybe a generation conflict, I "grew" up with "our"... ; )

      your right about the missing orthogonality of "local", I really miss the opportunity to use it with lexicals, maybe in a renamed form ("save"?). But IMHO you can't blame it on "our".

      Cheers Rolf

        If you think it is just a question of what I am "used to", then you need to read more carefully. If you don't understand how "vars" works, then you should correct that, because it is really simple and occasionally useful.

        What vars does is declare a certain global in a certain package so that strict will not complain about it. If you have a package that crosses files, the declaration will cover both (assuming it happens in the first one Perl compiles). If you declare a variable then change packages, the declaration stops having an effect. In short, vars actually works like ikegami claimed that our did.

        Simple, huh? What is it good for? In the unlikely situation that you want to share a global in 2 very different places, vars is the best way to do it. If in one file you need to declare something in another, vars is the only way to do it. (Luckily exporting a variable with Exporter also declares it, so you very rarely need to do that.) The only real benefit that our has over vars is that you can save one line on certain often-used declarations. (I don't consider obfuscation to be a benefit.) Other than that saving of typing, there is always a better way to do it.

        On the missing orthogonality of how you can use local, that is Larry Wall's executive decision. He thought that using local on my variables would be too confusing, and so has deliberately rejected patches that would change that. I definitely don't blame that on our, however it is a difference and I like keeping track of differences.

        But I personally don't often want to do local lexical variables. What has proven more useful for me is using local on the keys of a hash instead.