$ perl588 -we'$h{a}[0]{b} = 1; $h{a}{x}{y}=2'
Pseudo-hashes are deprecated at -e line 1.
No such pseudo-hash field "x" at -e line 1.
$
[download]

$galaxy{solarsystem}{planet}[year]{lat}{long}=’foo’;
[download]

Dave.

Deep structures like that seem to shout out OO to me. If data is hierarchial enough to warrant a deep structure, there must exist an organizing principle that can supply a class name for instances of data at each level. The advantage is that that conceptually flattens the huge data tree.

Your example data structure suggests exactly how that should go. Galaxies are gravitationally bound clusters of solar systems, rubble, dust and gas. Solar systems are gravitationally bound clusters of stars, planetary systems, rubble, dust and gas. Planetary systems are gravitationally bound clusters of planets and moons . . . with perhaps a little rubble, dust and gas.

Of your goals,

1. A non-programmer who knows even a little astrophysics will immediately understand what OO code based on that does. One who wants to expand it to superclusters or add a black hole to their galaxy's center of mass will have plenty of guidance. I wouldn't trust the coding details to a non-programmer, but they will understand well enough to provide specifications and realm advice.
2. There is clearly a fundamental base class, "Massive Object", and a base collection object, "Gravitationally Bound Cluster", which is itself an even more Massive Object. The various subtrees are instances of these, subclassed by other properties into "Solar System", "Star", "Planet", "Rubble", and so on. The subs which may act on a part of the tree are simply the object methods of whatever occupies that slot. Many of those will be inherited from the base classes. In particular, the methods of Massive Object can probably be called by any element of the $galaxy tree.
3. As long as you don't fiddle with pseudohashes in defining your classes, they won't bite. The OO principles used here are supported by any Perl 5.

The question that keeps niggling me is: Why do you want an array at that point?

Arrays are indexed numerically, and 'year' is not numeric. And if 'year' is a placeholder for 1999, 2000, 2001 etc., then I still don't understand why you want an array. Array's start from 0 (ignoring $[ which is totally impractical), which unless your application needs to deal with antiquity, means that you'll be reserving (a relatively small amount) of space for almost 2000 entries in each 'date' array that you will never use.

Remember, that's one array for every 'galaxy' * 'solar system' * 'planet'; depending upon the size of your universe, that adds up to a lot of dark matter wasted space :)

The advantages of arrays over hashes for numeric data are:

1. They are slightly faster
2. They use less memory

If you are only using indexes 2000 .. 2020 of 0 .. 2020, then you will pretty much completely negate the latter, and the former is unlikely to make any appreciable difference given that you are already doing 5 other levels of hash lookup. Stick with a HoHoH(oH...)--it will make your life much simpler. You might look at YAML for your multi-dimensional configuration data. It seems to be the simplest/clearest format for manually maintained data.

Finally, for contrast with Zaxo's advice--for the purpose of giving the ammunition to make up your own mind--compare iterating all the latitudes and longitudes for a given year and incrementing the number of occurances:

Using a HoH:

my $thisYear = 2005;
my $yearRef = $galaxy{ $sSystem }{ $planet }{ $thisYear };

for my $year ( keys %{ $yearRef } ) {
    for my $lat ( keys %{ $yearRef->{ $year } } ) {
        for my $long ( keys %{ $yearRef->{ $year }{ $lat } } ) {
            printf "$sSystem.$planet.$thisYear.$lat.$long:%s\n", 
                $yearRef->{ $year }{ $lat }{ $long };

            $yearRef->{ $year }{ $lat }{ $long }++;
        }
    }
}
[download]

Using OO:

my $thisYear = 2005;
my $yearIter = $galaxy->getYearIerator( $sSystem, $planet, $thisYear )
+;
while( my $year = $yearIter->() ) {
    my $latIter = $year->getLatitudeIter();
    while( my $lat = $latIter->() ) {
        my $longIter = $lat->getLongIter();
        while( my $long = $longIter->() ) {
            printf "$sSystem.$planet.$thisYear.%s.%s.%s\n", 
                $year->getYear(),
                $lat->getLat(),
                $long->getLong(),
                $long->getOccurances();

            $long->setOccurances( $long->getOccurances() + 1 );
        }
    }
}
[download]

Your choice ;)

I think that year, latitude, and longitude would wind up being parameters of the local coordinate system, hence either free variables or getters/setters. ;-)

After Compline,
Zaxo

My comments were somewhat tongue in cheek , but I would love to see an example of what you mean?

There would still need to be storage to hold whatever value are associated with each time/lat/long combination, and Perl's object system seems particularly inadaquate for dealing with this kind of aggregate data. Both Javascript and VB (from what little I know of it), seem to have a consistant syntax for this kind of thing, but perl's is particularly clumsy.

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

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

A relational DB with an arbitrary number of linked tables, with multiple indices should meet your needs - thery are plenty of free high-performance DB's, and you end up with an easily extensible, robust solution, which just happens to be perl-version independent.

On top of the database, it is possible to build objects, using modules like Class::DBI, and work towards incorporating Zaxo's(++) OO ideas on top of DB storage.

...how to best design a data structure which can match the requirements necessary and be future-proofed enough

Excellent question!

Fortunately, there is also an excellent answer!

The relational view (or model) of data described in Section 1 appears to be superior in several respects to the graph or network model [3, 4] presently in vogue for non-inferential systems. It provides a means of describing data with its natural structure only -- that is, without superimposing any additional structure for machine representation poses. Accordingly, it provides a basis for a high level data language which will yield maximal independence between programs on the one hand and machine representation and organization of data on the other.

Further reading