Re: iterating through array and saving matches to new array

Thanks POJ, et al. Let me abstract the problem to be sure I understand it: If I want to save matches to new array, and make it visible outside the foreach (or while, if, etc) then you are proposing not creating the block in the first place, and in cases where you have to use a code block, and return the new array, just use "my" and not "our" appears to be the take away.

Comment on Re: iterating through array and saving matches to new array

Replies are listed 'Best First'.
Re^2: iterating through array and saving matches to new array by AnomalousMonk (Archbishop) on Apr 15, 2018 at 21:13 UTC
... where you have to use a code block, and return the new array, just use "my" and not "our" appears to be the take away. The preference of a lexical (my) variable over a package-global (our) variable has nothing to do with accessing a value generated within a code block (or lexical scope, as I would express it). The code in the OP using a package-global to return the values produced in the `for`-loop scope works just fine as far as it goes. The problem is that you are then left with a global variable. As the old punchline goes, now you've got two problems. Global variables are officially Frowned Upon because they are... well, global: they can be accessed from anywhere in your program and can be the source of "spooky action at a distance" problems, potentially very tricky to debug. Lexical variables have a well-defined and potentially extremely limited scope (the more limited, the better), and can (usually) be reasoned about and debugged more easily. Don't give yourself headaches. Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: iterating through array and saving matches to new array
by AnomalousMonk (Archbishop) on Apr 15, 2018 at 21:13 UTC

... where you have to use a code block, and return the new array, just use "my" and not "our" appears to be the take away.

The preference of a lexical (my) variable over a package-global (our) variable has nothing to do with accessing a value generated within a code block (or lexical scope, as I would express it). The code in the OP using a package-global to return the values produced in the for-loop scope works just fine as far as it goes. The problem is that you are then left with a global variable. As the old punchline goes, now you've got two problems.

Global variables are officially Frowned Upon because they are... well, global: they can be accessed from anywhere in your program and can be the source of "spooky action at a distance" problems, potentially very tricky to debug. Lexical variables have a well-defined and potentially extremely limited scope (the more limited, the better), and can (usually) be reasoned about and debugged more easily. Don't give yourself headaches.

Give a man a fish: <%-{-{-{-<

[reply]
[d/l]
[select]