To be honest, I don't understand your data structure. ;-) But from what I can tell, you're mixing arrays and hashes a tad indiscriminately. If nothing else, this won't do what you seem to be expecting: $info->{subdirectory}->{file}->[measurement] = INDEX; If the last item is an array [], then measurement better be an expression that returns an integer.

However, I think I see an easy way up for you. Get thyself over to CPAN, and look at Class::Struct. It lets you set up nested data structures that may be familiar to you, coming from a C/C++ background.

HTH ... a little

Hmm... sounds very interseting. (the module, that is)

FORGIVE ME, however. IT was just pseudo-code I used in my notes--I should have explained the subdirectory, file, and measurement just mean a valid subdir, file, or measurement. I happen to use variable names in the code: $subdir, $file, and $meas. Sorry for the confusion.

A module is probably not a bad idea here, especially if you really need those range constraints (as per your example.) I would recommend taking a look at perldoc perldsc (the data structures cookbook that comes with Perl) for some examples of ADTs.

[ ['measurement1',
   [ ['test subject number', 21, 27], ['value', 50], ... ],
  ...
  ],
...
]
[download]

But you are trying to get at the data as if it is a reference to a hash:

$info->{subdirectory}->{file}->[measurement] = INDEX;
$info->{subdirectory}->{file} = PARSER;
$info->[measurement]->{name} = NAME;
[download]

But it is hard to tell given the examples you actually gave. Is $info a reference to an array or to a hash?

Also, you might find your code more readable if you only dereference where you need to do so. For instance, instead of $info->{subdirectory}->{file} try just $info->{subdirectory}{file}.

By the way, an "ADT" usually means an "Abstract Data Type" not an "Advanced Data Type." One person's advanced data type is another's basic data type.

I'd be happy to help if you provide a little more information.

-sauoq
"My two cents aren't worth a dime.";

Thank you ... don't worry too much over what I have. They were just notes basically, as what I have in my code *has* to change (I knew that basically when I was putting the code in -- I just thought that it might work :)

I think that the class::Struct is perfect for what I want -- the documentation sure got me exited so far anyway. I'll update this with more information if it doesn't work ... and thank's for all the help.

Now, as for the "ADT" part ... thanks. One of my classes sometime ago had a book (something like Data Types with C++, or ADTs, or something to that effect). Well, it talked about (beat into the ground) all about ADTs -- it's a shame that I remembered it incorrectly. Yes, I recall now that it is "Abstract"...that reminds me-- Data Abstraction with C++. Decent book, by the way.

As a note - while you're developing it, DO NOT deal with optimization. You have no idea what to optimize yet. Just use the easiest way to code it, then optimize later. Much, much later.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Objects aren't a magic wand that just make your problems go away. You still have the same potential problems if you are going to use an object. Don't forget, Perl makes you implement the objects yourself. All you have is a single reference, and you have to store all your instance data there. Guess what, then you are facing exactly the same problems! After all, the post is about storing data in a reference.... You still have to write your accessors.

Abigail

Yes, you are absolutely correct. I should have been more specific in my post.

What I was driving at was that he wasn't quite sure how the ADT was going to be specified. In fact, he says that the ADT's definition is constantly changing. This implies, to me, that he's using this thing. By creating some API, he is able to deal with the ADT in some abstract manner within the client. He gets to figure out what exactly he wants this thing's behavior to be.

Then, and only then, does he have enough information to be able to actually design the darn thing. He's trying to put the cart before the horse.

For example, I only skimmed the original post, but I'm pretty sure that he doesn't need one ADT, but a composition of ADT's.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

use Data::Dumper;
..
..
print Dumper(<insert datastructre here>);
[download]

Data Dumper is core, so you will have it as part of a vanilla install.