The double foreach loop is a whole lot easier to read though ;-)

I don't know. Maybe for a newbie, but I don't find it so. I have no trouble reading slice syntax -- I use it a lot -- and find the way it extends from 1D to 2D and so on, very natural and readable.

More importantly, I prefer the single line syntax to the multi-line because it makes it very clear that this is simply initialising the HoHs to a bunch of 1s, and nothing more. I like that I can read as "Initialise the 2D hash to 1s". There is little opportunity to misread the intent and screw it up by injecting extra stuff in the loops.

It would be even nicer if I could do (something like):

my %netifaces{ @eths }{ @nets } = (1) x *;
[download]

My point I guess is that this initialisation (whilst possibly important), is essentially a trival part of the overall algorithm, and having it as a single line gives it a weight commensurate with that.

Conversely, spreading it out over 5 lines with named iterators makes it take on a weight that makes it seem far more significant than it is in the overall scheme of things.

Ie. This is but a single step in the algorithm, and having it as a single line in the source code makes that very clear. Which I like, and feel is helpful when reading the overall algorithm.

I prefer the nested loops, because that makes it easier to change the value that is assigned. For instance:

for my $eth (@eths) {
    for my $net (@nets) {
        $netifaces{$eth}{$net} = func($eth, $net);
    }
}
[download]

The structure remains the same, regardless whether the RHS of the assignment is a literal, or a more complex expression.

Or it can be easily extended to initialize more structures:

for my $eth (@eths) {
    for my $net (@nets) {
        $netifaces{$eth}{$net} = func($eth, $net);
        $something_else{$eth} += $net;
    }
}
[download]

I prefer the nested loops, because that makes it easier to change the value that is assigned.

That is only a benefit if the initialisation value is likely to change to a per item initialisation value. But it isn't. Indeed, it is very, very rare that is required at all. And much rarer still that an algorithm will suddenly change from requiring bulk initialisation to per-item initialisation.

And the effort involved in the change on those extremely rare occasions, is so trivial, that expending any effort -- even thought -- to trying to optimise it, is the very definition of premature optimisation; the woe in O'Woe; the pointless in contrary counter-argument.

It's like carrying a gas mask with you everywhere you go. One day it might save your life -- but the odds are stacked so high against it, nobody does.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

That was exactly the feeling I had that drove me to post. It is indeed a trivial part of the whole program.