Opal - Ruby to Javascript compiler

While I never finished it, my "CappRuby" prototype supported method_missing since it compiled to use the Objective-J runtime. https://github.com/tlrobinson/cappruby

Javascript Harmony (ES6) Proxies will allow to define getter catchall and other kinds of traps.

See https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

Opal does support method_missing, it's just off by default, i.e. opt-in.

It's really not terribly complicated to figure out what it does, here's the formatted version for adding two numbers

    (function() {
          var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice;
          var __a, __b;
          return self.$puts((__a = 1, __b = 2, typeof(__a) === 'number' ? __a + __b : __a['$+'](__b)))
    })();

In terms of having to ever debug something like that, I agree that it'd probably be a huge pain.

In Ruby 2100 is an exact integer. In JavaScript, it is promoted to a poor floating point approximation. If you want to try to preserve Ruby's numeric semantics, you can't use native math.

It makes sense, considering JS's silly coercion rules and overflow, which don't match Ruby's.

the problem is that ruby lets you redefine + anywhere you like, and return values of any type. so you need the most general translation of that expression into a series of method dispatches.

Could probably also include something like Sugar.js or Underscore.js that tries to bring a lot of the missing syntactic sugar to JS.

I think what you've described would be mostly accomplished by source maps: http://www.html5rocks.com/en/tutorials/developertools/source...

Why is it not possible to engineer a basic VM to do this job from the start, rather than retrofitting Javascript to act as a bytecode?

>RubyScript is what we need => efficient code, à la coffeescript, with a Ruby syntax.

Why not make a Ruby -> Coffeescript compiler, since they're a lot closer in the first place?

ECMA5 has real maps, which Opal could use. Some browsers support them already.

If you look at this rationally, it's actually pretty sane. It's just very simple JavaScript OOP inline with translated code. Even more beautiful is the output of modules:

     module Run
       def run
         puts "I am running!"
       end
     end

     module Jump
       def jump
         puts "I am jumping!"
       end
     end

     class Foo
       include Run
       include Jump
     end

     mario = Foo.new
     mario.run
     mario.jump

     (function() {
       var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice, __module = __opal.module, __klass = __opal.klass;
  
     	// Define Mario
     	var mario = nil;
  
     	// Javascript "Run" class
     	(function(__base){
         // line 2, (file), module Run
         function Run() {};
         Run = __module(__base, "Run", Run);
         var Run_prototype = Run.prototype, __scope = Run._scope;

         Run_prototype.$run = function() {
      
           return this.$puts("I am running!");
         }
             ;Run._donate(["$run"]);
       })(self);

     	// Javascript "Jump" class
       (function(__base){
         // line 8, (file), module Jump
         function Jump() {};
         Jump = __module(__base, "Jump", Jump);
         var Jump_prototype = Jump.prototype, __scope = Jump._scope;

         Jump_prototype.$jump = function() {
      
           return this.$puts("I am jumping!");
         }
             ;Jump._donate(["$jump"]);
       })(self);

     	// JavaScript "Foo" class
       (function(__base, __super){
         // line 14, (file), class Foo
         function Foo() {};
         Foo = __klass(__base, __super, "Foo", Foo);

         var Foo_prototype = Foo.prototype, __scope = Foo._scope;

     	 // $include Run / Jump
         Foo.$include(__scope.Run);
         return Foo.$include(__scope.Jump);
       })(self, null);

     	// The ruby executing code translation
       mario = __scope.Foo.$new();
       mario.$run();
       return mario.$jump();
     })();

The difference is that CoffeeScript was designed to compile to JavaScript, so it can adopt JavaScript semantics.

Ruby doesn't have the same semantics as JavaScript, so you can't have a 1-to-1 mapping of language constructs.

OpalScript is going to solve this problem

Seems so: > Document['.post .title'].html = @post[:title] Document['.post .body'].html = @post[:body] Document['.post .comments'].html = comments_html

From https://github.com/opal/opal-rails#readme

Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.

If you can perform computation on the client, you can avoid some round trips to the server. Of course, you can't trust the client, so you still need to perform (some of) the same computations on the server.

If you can use the same code for both client and server, then it opens up the possibility of sending chunks of logic over the wire.

Here's a trivial example: a website uses Markdown for comment formatting. You can improve the feedback cycle, especially for those who aren't overly familiar with Markdown, by rendering a preview on the client side. However, this means that you need two Markdown parsers, one in your server-side language, and one in JavaScript. That's a potential duplication of effort. Someone has already written a JS Markdown parser, but it might not have exactly the same behaviour as your server implementation. So why not just write the code once and have it work on both sides?

I have a feeling that there are a lot more interesting things that you can do with split computation, but I haven't seen many examples yet. I think they'll come.

Rewriting your entire Rails app in Node so that it goes faster!

Porting existing code without having to re-implement. Keeping a single reference implementation of a particular method.