I was mistaken. Should have paid a little more attention while reviewing extending and embedding perl. $hash in the following structure refers to the hashed value of the key, not the hashtable from which the HE came. Confusing terminology.
# from Extending and Embedding Perl, section 4.5
$HE = {
NEXT => $HE_next,
HEK => {
HASH => $hash,
LEN => length($key),
KEY => $key,
}
VAL => $SV,
};
My approach didn't try ordering, so the hash was actually based on a hashref, not an array.
I looked over the tie modules on CPAN (the first 20 pages before I got bored). None of them seemed to implement the functionality of what I envisioned as a solution: A tied hash that gives defered processing objects as results.
Being interested in something in inverse proportion to how useful that thing is, I expanded upon my ideas in the previous post. I think it caught feauture-use-itis though (2 tie classes and an overloaded inside-out class is a bit much complication for one module, IMHO).
I called it Tie::LazyHash, but it probably would be better named Tie::DeferredLookupRefHash. But that's just ugly sounding.
You can do a couple of things with the lookup values that invoke the actual lookup (which can be invoked multiple times for the same object):
$elem->delete;
$elem->exists;
$$elem = $x;
print $elem; # overloaded for convenience
print $$elem;
| [reply]
[d/l]
[select] |
