Re^2: A Perl vs. Java fight brews

Java will require something like value = hash_name.get( key_name ); instead of the more compact value = hash_name{key_name}. This is magnified for, two or three dimensional hashes, for example compare $myhash{$key}{$key2} to myhash.get(key).get(key2).

Don't forget about the need for casting, which makes matters worse. Java "hashes" (Java has many basic hash types, so you have to choose an implementation first) can contain any kind of object, so when you retrieve a value, you have to tell it what kind of object it is, before you can do anything with it. So your nested hash example really has to become more like

value = (datatype)((hashtype)myhash.get(key)).get(key);
[download]

where datatype and hashtype need to be replaced with the real class names for the kind of objects you're using. Are you appalled enough, yet?

Comment on Re^2: A Perl vs. Java fight brews Select or Download Code

Replies are listed 'Best First'.
Re^3: A Perl vs. Java fight brews by philcrow (Priest) on Jul 25, 2006 at 13:23 UTC
Don't forget about the need for casting, which makes matters worse... Well put. This is what I was alluding to when I said this in passing: Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled). You can usually get around constant casting by making some classes of your own that explicitly return String types, then all the casting happens in those classes. But it is still a pain. Phil	[reply]

Replies are listed 'Best First'.

Re^3: A Perl vs. Java fight brews
by philcrow (Priest) on Jul 25, 2006 at 13:23 UTC

Don't forget about the need for casting, which makes matters worse...

This is what I was alluding to when I said this in passing:

Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled).

Phil

[reply]