Oooo, This does raise some interesting options. Not long ago I was writing a CORBA system with Perl on the server and a Java client. Of course there are hashes all over on the server since the API is in Perl, but hashes aren't a basic type in Java, and they sure aren't in OMG IDL. My simple solution was to map hashes to multidimensional arrays in IDL, but then the client has to do a lot of nitpicking array handling (esp. since it's Java :P )
A better idea might be a general IDL interface defining a set of hash functions. But on the server side it wouldn't work to tie the hash to the 'CORBAHash' b/c the tied hashes are just proxy objects, and the remote reference used by the client will necessarily point to the instance of CORBAHash, not the tied hash. So, on the server side, the CORBAHash would have to be a wrapper class around the hash with the data you want.
What would be nice is to reverse the tie(), so that you could tie an instance of a class to a populated data structure, as in:
But then you might as well just pass the hash into the constructor of the remote implementation class. So, I think what you'd want is:
return $corba_hash; # return to the client
If the client were in Perl, you'd want to be able to say:
$ORB->activate($hash); # register object with the ORB
return $hash; # return to the client
To make this work I think you'd have to write the TIEHASH method to call a remote factory method, since the whole point is to tie the hash to a remote object. The factory method produces a remote object reference with the hash interface, and then it's just a matter of the local Perl interpreter to link the hash reference to the remote reference.
Update: I'm using the COPE language binding for Perl.