They're both doing the same sort of things and therefore worth having a more consistent API.
Some points on the current Ruby interfaces:
Both IdPacker and UuidPacker are classes, so perhaps their base_string or whatnot can be made an instance variable instead.
Their JS counterparts would also need to follow.
Or we could make them both singletons. But then base_string would need to be kept at the call site and fed to the encoding/decoding functions every single time, which seems to be working against the most common use cases.
Some other points, on both Ruby and JS:
Since encode_sync_str & decode_sync_str already work for both UUID and integer ID, it should be moved from IdPacker to a more common namespace.
This requires changes in both Ruby and JS implementations.
This is a breaking change so will need to bump gem's minor version when released.
They're both doing the same sort of things and therefore worth having a more consistent API.
Some points on the current Ruby interfaces:
IdPackerandUuidPackerare classes, so perhaps theirbase_stringor whatnot can be made an instance variable instead.base_stringwould need to be kept at the call site and fed to the encoding/decoding functions every single time, which seems to be working against the most common use cases.Some other points, on both Ruby and JS:
encode_sync_str&decode_sync_stralready work for both UUID and integer ID, it should be moved fromIdPackerto a more common namespace.This requires changes in both Ruby and JS implementations.
This is a breaking change so will need to bump gem's minor version when released.
Ref: #21