Re: multiple layers of referencing and dereferencing

[Herkum]

There are two measures when it comes to coding.

1. Does it do what it is supposed to do?
2. Can I look at the code and easily understand what the code is supposed to do?

Most programmers(which are bad programmers) stop at step 1 because most people are not going to check the code that the wrote unless there was a bug.

As for 2, can you really tell me that code is understandable? Come on, it is just a bunch of numbers, it conveys nothing except you learned what a reference is.

Let me ask you a simple question, do you believe that this a well written program? Do you think our most learned Perl monks like chromatic, corion, or theDamian ( no offense for missing the several hundred other talent monks out there ) would write this sort of code? I believe you know the answer.

[Bruce32903]

Instead of stating that some of the syntax looked "rather messy" I should have been a little more honest and stated that I don't really like any of it.

I think that my question and supporting code reflect a well thought out and well organized (please don't flame my yet) attempt by someone that is asking the question because they understand that they still don't quite "see the way". It was never my intention for "not too bad" to suggest "good". I did not like the "not too bad" code, but at least I didn't have to take time to count all the opening and closing curley brackets and square brackets to see if they matched up.

Perl is easy to get started with and hard to get good at. Perhaps I should have given my question the title "Help me with the issue of most other languages allowing arrays to have multiple dimensions and perl does not".

Actually, a good tutorial for someone good at perl to write would be "Multi Dimensional Arrays The Perl Way". Many of us "part time programmers" who spend most of our "part time" in other languages find it easy to stray to the "Dark Side" when we try to organize large collections of data in perl. If we are lucky enough to be able to read the full book and fully understand the full book before we program then we might "see the light" before we program. There are a lot of us out here who are not full time programmers and are forced to learn programming in small snapshots.

Not having multiple dimensions for arrays is one of the areas that cause trouble for "part time" "snapshot" programmers. And, to make matters worse, (and if I recall correctly) when we break code up into separate files to support reusing utility sections then we are forced to use references to pass data to subroutines. Wow, now I understand why I was seeking wisdom.

[Herkum]

The advice I would give you then is that hashes are for context and arrays are for order.

Things that you don't need to know the order of should be in some sort of hash because the keys of a hash give the data context. Example:

my @cats = qw(persian siamese cute);
my @dogs = qw(doverman bulldog);

## Bad data structure
my @data = (\@cats, \@dogs);

function( \@data );

## Good data structure
function1({
  cats => \@cats,
  dogs => \@dogs,
});

The first example with a bad data structure requires explicit know of the exact order of your arguments to know where cats and dogs are. In addition if you just deference the data you still don't necessary know what you are working with. Don't do it.

The second example explicitly designates which array references go with what type of data. Your funtion() will need to deference the data via a name which puts your code into a context which makes it easier to understand.

sub function1 {
    my $params = shift;

    warn "My Dogs\n";
    for (@{$params->{'dogs'}}) { warn "\t$_\n" }

    warn "My Cats\n";
    for (@{$params->{'cats'}}) { warn "\t$_\n" }
}

Hope this helps.