Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^3: Unclear about 'our'

by BillKSmith (Monsignor)
on Dec 28, 2022 at 17:01 UTC ( [id://11149165] : note . print w/replies, xml ) Need Help??


in reply to Re^2: Unclear about 'our'
in thread Unclear about 'our'

The reason our appears to have little advantage over my is that you are misusing my.

In the modules and programs I've written, I typically declare a bunch of 'my' variables up top, outside of any blocks, which subsequent subroutines can freely access.....

Although this 'works', it is considered poor practice. It defeats the advantage of using my with use strict. Lexical (my) variables should be declared in the smallest possible scope. Accidental usage elsewhere will be detected at compile time. It is often useful to declare the same name in different scopes. (They actually refer to different variables). Both structured design and the newer object-oriented design discourage using subroutines that share a common pool of variables. Subroutines that do are much harder to test and debug than those that do not.

Bill

Replies are listed 'Best First'.
Re^4: Unclear about 'our'
by ikegami (Patriarch) on Dec 30, 2022 at 14:56 UTC

    Both structured design and the newer object-oriented design discourage using subroutines that share a common pool of variables

    Structured code does not preclude shared variables.

    And the basis of OOP is the association of attributes (variables) with methods (subroutines). It's literally built around a common pool of variables.

Re^4: Unclear about 'our'
by ibm1620 (Hermit) on Dec 28, 2022 at 17:45 UTC
    I think it's fair to say that, in object-oriented design, the fields/attributes/properties/member variables of a class are a common pool of variables shared by subroutines/methods. In fact, I've come to think of these as "globals with discipline", which is generally my thinking when I declare the variables I mentioned.

    However, as HaukeX suggested, it might be time to learn to write OO Perl. :-)

      I think it's fair to say that, in object-oriented design, the fields/attributes/properties/member variables of a class are a common pool of variables shared by subroutines/methods.

      I'd look at it differently - while of course the subs are part of the class and technically all objects of the class share them, each object is a separate entity, so I'd look at it as each object having its own copy of the instance variables - or in Perl, really just one variable, typically referred to as $self. I would not expect to see any variables declared outside of the subs of the class, perhaps the only exception being default settings like I showed here.

      (The concept of Inside Out objects also exists, but I practically never see that in the wild and personally wouldn't suggest it.)

        I see what you mean. Now that I have read a bit about OO Perl I see that what I've been creating would be considered "class variables" (a.k.a. static member variables) in C++, which is the extent of my OO experience. As you point out, they have their place, but they're not the same as instance variables.
Re^4: Unclear about 'our'
by LanX (Saint) on Dec 28, 2022 at 17:07 UTC
    > discourage using subroutines that share a common pool of variables

    I have to disagree in this generality, closures are a common technique.

    Cheers Rolf
    (addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
    Wikisyntax for the Monastery

      I have to disagree in this generality, closures are a common technique.

      I'm confused by this comment, could you show a code example of what you mean?

      My understanding of BillKSmith's node is that it is arguing against file-scoped lexicals that are used by multiple subs in the file, and I fully agree with that.

        One contrived example, using a private config-val instead of a public package var.
        my $config = 42; my $change_allowed = 0; sub mult { $_[0] * $config } sub get_config { $config } sub set_config { $config = shift if $change_allowed; } # yadda

        of course you could also put only those subs inside an extra block together with the closure var.

        Cheers Rolf
        (addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
        Wikisyntax for the Monastery