Re^2: Printing to stdout an array of strings and scalar references

Hi Ken

Thanks for your help,
To clarify I generally do pass variables into my subroutines, the use of global's in the sample code was for demonstration purposes, as was the newline feed at the end of the output line, it was purely intended to demonstrate the output without having to introduce delays.
I have never really understood the uses of anonymous blocks of code, your explanation and code sample has helped to clarify why I might need to use that method in the future, and I will also check out state as you recommend.
I have traditionally turned on Autoflush globally when I need it (as indeed I do for the purposes of the progress indication), I notice you are scoping it as a local to the subroutine, is there an advantage to this method? or alternatively a disadvantage to using autoflush globally?
sprintf is also something I have not used much, but I can see how your code could be adapted to achieve the variable output I require without resorting to references within the array so I will also put more effort into understanding how it works.

Thankyou for your assistance, it has been educational :-)

Comment on Re^2: Printing to stdout an array of strings and scalar references

Replies are listed 'Best First'.
Re^3: Printing to stdout an array of strings and scalar references by kcott (Archbishop) on Oct 25, 2017 at 07:10 UTC
"Thanks for your help" You're very welcome. "I have traditionally turned on Autoflush globally when I need it ..., I notice you are scoping it as a local to the subroutine, is there an advantage to this method? or alternatively a disadvantage to using autoflush globally?" Perl has a number of special variables (see perlvar). Some of these are set in a certain context (`$a` - sort; `$1` - regex; `$@` - eval; and so on). Others have default values which are usually fine and don't needed changing; code is written expecting these default values; changing them globally can mean that some code does not function as intended or expected. Changing them with `local`, in a limited scope, means the change does not affect other code: `$ perl -E 'say $\|; { local $\| = 1; say $\| } say $\|' 0 1 0` [download] If you look in "Variables related to filehandles", you'll see (a few paragraphs down): "You should be very careful when modifying the default values of most special variables described in this document. In most cases you want to localize these variables before changing them, since if you don't, the change may affect other modules which rely on the default values of the special variables that you have changed. ..." That continues on with good and bad examples. A discussion of scope follows that: "Usually when a variable is localized you want to make sure that this change affects the shortest scope possible. ..." There are more good and bad examples; one showing use of an anonymous block. Further related information can be found in perlsub; in particular, the sections "Temporary Values via local()" (especially the "Localization of special variables" subsection), and "When to Still Use local()". — Ken	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Printing to stdout an array of strings and scalar references
by kcott (Archbishop) on Oct 25, 2017 at 07:10 UTC

"Thanks for your help"

You're very welcome.

"I have traditionally turned on Autoflush globally when I need it ..., I notice you are scoping it as a local to the subroutine, is there an advantage to this method? or alternatively a disadvantage to using autoflush globally?"

Perl has a number of special variables (see perlvar). Some of these are set in a certain context ($a - sort; $1 - regex; $@ - eval; and so on). Others have default values which are usually fine and don't needed changing; code is written expecting these default values; changing them globally can mean that some code does not function as intended or expected. Changing them with local, in a limited scope, means the change does not affect other code:

$ perl -E 'say $|; { local $| = 1; say $| } say $|'
0
1
0
[download]

If you look in "Variables related to filehandles", you'll see (a few paragraphs down):

"You should be very careful when modifying the default values of most special variables described in this document. In most cases you want to localize these variables before changing them, since if you don't, the change may affect other modules which rely on the default values of the special variables that you have changed. ..."

That continues on with good and bad examples. A discussion of scope follows that:

"Usually when a variable is localized you want to make sure that this change affects the shortest scope possible. ..."

There are more good and bad examples; one showing use of an anonymous block.

Further related information can be found in perlsub; in particular, the sections "Temporary Values via local()" (especially the "Localization of special variables" subsection), and "When to Still Use local()".

— Ken

[reply]
[d/l]
[select]