Relax MAX_NUMBER restriction

[iggymoran]

I understand the desire to be completely compatible with the Javascript implementation/limitiations, as explained in #47 and in the docs, but is it possible to provide a toggle that disables this functionality?

This would ensure backward compatibility with Javascript's limitations, but would allow this library to make use of the full potential that the Java platform provides.

Other implementations (such as Scala and .Net) don't impose these restrictions and allow the library to be used with the native implementation of the number.

[arcticicestudio]

I've also proposed this in another issue some time ago and if I remember correctly they planed a v2 which will include some breaking changes like this, but I implemented my own library including this feature. I've found no reason to limit a Java implementation only because the reference algorithm implementation is limited by the chosen language.
This library is used within the Java world and even if generated Hashids are e.g. used in a REST API to disguise internal database IDs which will be consumed by a JavaScript frontend, the part of the "decryption" will be handed in the backend (this library) while the frontend handles the Hashid as simple string and not a number.

[0x3333]

The initial proposal was to be interoperable. See #55

[arcticicestudio]

Might be interesting that there is a new TC39 proposal that introduces BigInt to JavaScript, so the current limit will be kind of obsolete.

[fanweixiao]

@arcticicestudio I think we should follow hashids main project spec, to keep exact result in different languages.

[0x3333]

I was thinking about this issue, and I believe that the best path is to allow bigger numbers when the user explicitly allow incompatibility with the original spec. This way we can have a version that follows the original implementation and also allows users to loosen up the spec a bit. Something like "strict mode", which is compatible with the original spec, and a "relaxed mode" which is more javaish.

[fanweixiao]

Yep, and I’d suggest a PR or Fork for this.

On Thu, May 3, 2018 at 18:05 Tercio Gaudencio Filho < ***@***.***> wrote: I was thinking about this issue, and I believe that the best path is to allow bigger numbers when the user explicitly allow incompatibility with the original spec. This way we can have a version that follows the original implementation and also allows users to loosen up the spec a bit. Something like *"strict mode"*, which is compatible with the original spec, and a *"relaxed mode"* which is more *javaish*. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEAQ56RLW0_4Chyoq1pE12QGdB3HcYDks5tutZSgaJpZM4TltqP> .

-- Sent from Gmail Mobile