Re: Re: hash, a troublemaker?

This is rather ugly, you have a set of lookups for various values without correlation to structures, while the opening example does have problems of hash abuse with misspelling, I'd MUCH rather see field identifiers as constants and an HoH as a datastructure rather than having unaffiliated fields.

i.e. $records{$person}{$K_AGE}
[download]

That way you keep records grouped. Since Perl doesn't have real structures of any merit, the next logical step is to go to an OO representation and use functions/etc (maybe one of those MethodMaker deals) to prevent accidental typos.

At minimum, the Hash::Util method provides locking while preserving the logical representation of the data (edit: and clean Data::Dumper dumpability!).

Keeping fields seperated without context, IMHO, is the worst thing you can do.

Comment on Re: Re: hash, a troublemaker? Download Code

Replies are listed 'Best First'.
Re: hash, a troublemaker? by Abigail-II (Bishop) on May 12, 2004 at 14:17 UTC
This is just the same technique I use for InsideOut objects, so going to an OO model wouldn't be much of a change for me. `;-)`. And if you use functions, you can still make typos in the functions when you access the attributes - which is why I developed InsideOut objects in the first place. Abigail	[reply]
Re: Re: hash, a troublemaker? by flyingmoose (Priest) on May 12, 2004 at 14:26 UTC
yep, that's a lot cleaner when the collections of fields start having namespace...	[reply]
Re: Re: Re: hash, a troublemaker? by Doraemon (Beadle) on May 12, 2004 at 14:35 UTC
Sorry Abigail-II :) I agree with flyingmoose. Related fields should be grouped together, with a name represent these related data. At this point i strongly support the reference mechanism, but somehow, we need to create a reference that have information about the data that it's pointing to.	[reply]