Okay, Google defines a "hash code" as:

A way of getting a number from an object so it can be stored in a Hashtable.
If the number isn't allowed to infinitely grow, but the string from which it's derived is, then it will, by definition be a lossy hashcode.

I see a hash code as a form of compression. It's taking a large chunk of data and making it into something that's smaller and more manageable, and probably numeric. There would be several ways to go about doing this, some lossy and some lossless.

I was first introduced to the Lossy and Lossless terms with respect to sound, image, and video compression. For instance, with respect to images, bitmaps are lossless and jpegs are lossy. In other words, once you convert a bitmap to a jpeg, there's no way to the the absolute same bitmap back from that jpeg. However, if you turn a jpeg into a bitmap, and then back into a jpeg again, if the exact same encoding/decoding is used, you can get back to the same jpeg because a bitmap is lossless.

However, DEXWERX, I suspect you may know all of that, and it's strange that you asked.

Therefore, if Collection keys are using a hash code (which I seriously doubt), then it's a lossless hashcode because it's possible to recover the precise string that went into making it.

Regarding credit to LaVolpe, all I know is that the code I have has his name attached to it as the author. Maybe he'll come back around and affirm-or-deny his authorship.

Regards,
Elroy