(My hunch is that your inlined check would actually be slower than just calling the method, actually. If you just do a method call, the inline caching will optimize it away in many cases.)
> I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything.
All I was trying to demonstrate was just that. If you want a new language that runs in a browser, you can have:
1. Different (presumably better) semantics from JS.
2. A simple compiler that generates readable JS.
3. Performance competitive with raw JS.
By belief is that for a client-side language (i.e. a language that runs on the end user's hardware, which you don't control), that you don't have the luxury of sacrificing perf. You can in a server-side language since you can just throw more hardware at it. That's why languages like C++ still dominate client-side apps and games.
Given that, I don't think a language that targets the browser can really discard #3 and expect to get a decent number of users. Given that I love different languages, I'd be happy to be proven wrong here.
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:
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.