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.
| [reply] |
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. :-) | [reply] |
|
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.)
| [reply] [d/l] [select] |
|
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.
| [reply] |
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.
| [reply] |
|
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.
| [reply] [d/l] |
|
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.
| [reply] [d/l] |
|
|
|