riboseinc / id_pack

Pack UUID and integer ID sets in Ruby and JS
https://www.ribose.com
MIT License
1 stars 0 forks source link

Keep JS implementation in sync with Ruby #16

Open ribose-jeffreylau opened 6 years ago

ribose-jeffreylau commented 6 years ago

What would be a good way to keep the two implementations in sync?

One way would be to use opal, and have it compile the Ruby version to JS.

What are other good ways?

Keep in mind that the current JS and Ruby implementations for UuidPacker do have some descrepancies. #14

ribose-jeffreylau commented 6 years ago

cc: @skalee

skalee commented 6 years ago

Yes, Opal is an option. Though I don't know how heavyweight it is.

Other ideas that come to my mind are:

  1. Keep implementations separate, just rework the test suite so that all examples are run against both implementations, especially edge case tests.
  2. Use Ruby2JS. I have no experience with this tool, never seen it before, I've just found it in the Internet. But it exists for several years, looks quite mature, and is maintained. I believe it may be a more lightweight solution than running whole Ruby VM in a browser.
  3. Rewrite that packer to JavaScript and run from Ruby with some ExecJS, Ruby Racer, etc.
  4. Rewrite that packer in a language which can be used with or translated to both JS and Ruby. For instance, C code can be compiled to JavaScript with Enscripten, and used in Ruby as C extension; Java can be compiled to JavaScript with JSweet, and used in JRuby.
ribose-jeffreylau commented 6 years ago

Opal does have its disadvantages. I've had a little go on it, but it failed to run the translated version of Array#pack as it's not yet implemented.

  1. Keeping implementations separate could work, and allows for language-specific deviations, but it means giving up DRYness for such flexibility. This is the current state.

  2. Haven't tried Ruby2JS, yet. It also has a list of unimplemented things, but may not matter much in our case.

  3. We already have JS versions of both IdPacker and UuidPacker, so JS -> Ruby is definitely an option.

  4. Interesting idea!