It is a tradeoff for speed. Defining the standard hash such that each key is forced to be a string allows the lookups to dereference keys to be very fast indeed.

Since the requirement for objects (ie real, unstringified references) as keys seems to be rare, it makes sense to gain the extra speed for the common case. Since Tie::RefHash is available, the additional inconvenience for this rare case is small, so it seems still to be a good trade.

If I understand correctly, the plan for perl6 is to allow access to alternate behaviours by a different mechanism (declare a property on the hash) which will make it easier to switch in much faster implementations than perl5's tying mechanism allows, but the underlying tradeoff will remain the same - the default will be the implementation that allows fastest key lookup, ie strings.

Abigail

Devel::Pointer but don't tell anyone I told you:)

---

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.