Thank you for this forum.
It would be like using the same pointer/index but under another key
nid stands for "Numeric ID" and would be a sequential autoincrement integer.
For coding simplification, the concept of NID does not need to be an integer autoincrement. It coul be the memory cell where it the info is stored or the hash used to index it. The integer approach means you compress the key as it allows you use the Nid instead the key as data in other related hash tables.
You can think about storing IP's. On some servers, all IP's are transcoded into something like 5alphnum.5alphnum.virtual . And you can also customize your ip into whatever you can type like "I.hate.virtual.alphnum.ips". It would be very efficient to be able to access such an ip or a long nicknake either through the item in itself and through a numeric id
Possibly it would make it suitable to enable a Nid access function like $hgetnid( htable, Nid ) . I would not say it sounds like a complex coding task. Same data, two indexes.
You could emulate it but at the cost of duplicating (already long) data, and avoiding duplicity of large strings is what I suggest the feature for.
I guess it is needless to say what shocking power this woulkd give to the hash table system.
Please mention me if you decide to code it.

Last edited by M_A_; 17/09/15 09:41 AM. Reason: Adding a clarification