elia

The connection is that while coding you get the contents through a visual representation, it's the same connection between any content and the medium through which comes to you.

> If you've got a way to compile Ruby to JS that has tolerable arithmetic perf and doesn't do type analysis or generate a huge volume of code, I would definitely like to know more about it.

Yeah, that's kinda the point, you can do that and preserve Ruby semantics?

Let me note here that is a strawman indeed, Dart has frozen classes, Ruby is a bit different. In order to do something like that you should inline a ton of ternary operator to check if the method has been redefined on that particular object.

Something like:

    (a._isNumber && !a._plusRedefined) ? a + 1 : a['$+'](1)

plus listening on new method definitions to set `_plusRedefined`.

It's definitively a trade off, readability will suffer.

Opal had optimized operators in the past (that assumed native operations on numbers), they could even be back in the near future. But what I see here is a comparison of two different language semantics. I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything. What can be argued instead is that JS VMs could and should do that for us.

I had the same fear at first, but actually if you generate dynamically a method name you need to use `#__send__` (and friends) to call it.

Of course `#__send__` supports method_missing: https://github.com/opal/opal/blob/0-6-stable/opal/corelib/ba...

worth it