These are chat archives for opal/opal

29th
Mar 2016
Jamie Gaskins
@jgaskins
Mar 29 2016 03:21
@elia: It could fall back to the current implementation if the browser doesn't support Map, but I'm curious how you can get a Map to support hash. I've tried and couldn't get it working. I thought valueOf would do the trick, but it didn't. :-\
I assume each value in the map would be an array for hash collisions, which is what got me to try it out.
But if this can be used as a progressive enhancement, hashes would likely get a whole lot faster on modern browsers. And then once you decide to drop support for older IEs, you could just remove the JS-object fallback.
Forrest Chang
@fkchang
Mar 29 2016 18:15
@/all do we have a current "best way to structure an opal gem"? I know we have changed practices a bit over time
Jamie Gaskins
@jgaskins
Mar 29 2016 20:08
@fkchang I really like the lib / opal split for gems that have separate server-side and client-side code. I like to put code that runs in both environments in shared. If the whole thing is shared (GrandCentral does this, for example), I just do it all in lib: https://github.com/clearwater-rb/grand_central/blob/537a54d1d94a12bdfa3531d31954c004384e766f/lib/grand_central.rb
Elia Schito
@elia
Mar 29 2016 21:11
@fkchang can confirm that the "best" way is what @jgaskins said, sooner or later I'll bring back the split to opal-jquery too. Even if having everything is cooler separating stuff is less confusing.
@jgaskins my idea was not to use Map directly as iirc it lacks too many features, but rather to just use it as the hash-table implementation ($$map) which of course further defeats any gain over plain JS objects vs. lack of support and cost of reimplementation.
Forrest Chang
@fkchang
Mar 29 2016 21:33
@elia @jgaskins thx