Closed nkavian closed 3 years ago
Sorry for the late response.
This library is a re-implementation of the Javascript version, for compatibility reasons, I believe this should not be changed.
Reference: https://github.com/niieani/hashids.js/blob/master/lib/hashids.ts#L275
Not a problem, I've since moved away from hashid and use a different solution.
I understand the JavaScript compatibility concern. You could have still considered how to make this configurable to be more amenable to how things should work performantly in Java.
The very end of
_decode
performs athis.encode
and compares it with the original.Can you make it configurable if someone wants this type of redundancy check (via some constructor flag) or just altogether remove it. I haven't measured performance but this seems like it will affect performance.
It also seems arbitrary to
encode
at the end of_decode
to perform the check. You could have arbitrarilydecoded
at the end of_encode
, but if you did it would become recursive...Returning a simple
long[0]
does not help much as it is silent and preferably to make it explicit with an exception.Talking out loud here, but perhaps the right solution is to allow the developer to perform the
encode
/decode
checking in their own code if they desire that level of verification and allow the library to optimize its performance?.