Fooand a subclass
Foo's constructor from
Bar's looks like:
Bar.__super__.constructor.call(this, a, b);whereas in the Closure Library, the canonical thing is to do the following, identifying the superclass function directly:
The only minor drawback to using the CoffeeScript form when using Closure (though note that you would have to use
__super__) is that the CoffeeScript call is more bytes of code. Unfortunately, the Closure Compiler does not know that
Bar.superClass_.constructoris equivalent to
Foo, so it does not rewrite it as such, though such logic could be added to the Compiler.
This piqued my curiosity about how
goog.base()is handled by the Compiler, so I ended up taking a much deeper look at
goog.base()than I ever had before. I got so caught up in it that I ended up composing a new essay on what I learned: "An Examination of goog.base()."
The upshot of all this is that in my CoffeeScript-to-Closure translation code, I am not going to translate any of CoffeeScript's
goog.base()calls because avoiding
goog.base()eliminates a couple of issues. I will still use
goog.base()when writing Closure code by hand, but if Closure code is being autogenerated anyway, then using
goog.base()is not as compelling.
Finally, if you're wondering why I started this project a few weeks ago and have not made any progress on the code since then, it is because I got married and went on a honeymoon, so at least my wife and I would consider that a pretty good excuse!
Want to learn more about Closure? Pick up a copy of my new book, Closure: The Definitive Guide (O'Reilly), and learn how to build sophisticated web applications like Gmail and Google Maps!