CoffeeScript __extends vs util.inherits (Inheritance in JS)


#1

I have been writing a plugin in vanilla JS and ran into some trouble extending View. The problem is that class in CS differs from inherits in node. “class” is compiled to use the function __extends:

__extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } ...

while in the case of inherits:

util.inherits(constructor, superConstructor)

“The prototype of constructor will be set to a new object created from superConstructor.”

The difference is important. CS copies functions from parent to child on top of setting the prototype while the std library just does the latter. Inheriting from require(“atom”).View breaks without doing this manually
(which isn’t obvious at all). If this is not being done for performance, it should be documented; otherwise, those methods should be moved to the prototype.


Package "JS" generator (generates in Javascript)
Are there any Atom users who aren't hacking Atom?
Goodbye Atom, some feedback
#2

I agree. Imo, we should be allowed to accomplish inheritance from the public API in the standard JavaScript fashion. I think it’s great that they’re using CS outside of the browser world, but it would make more sense for the public API to be idiomatic JavaScript since JS is the common denominator of all languages people are going to use.

Has anyone been compiling a list of these kinds of CS oddities of which us JS folks need to be aware?

(Disclaimer: I haven’t verified that inheritance does not work in the standard JS way; I don’t have my invite yet)


Why coffeescript?
#3

So far, just View is busted to my knowledge (without copying over the attrs). However, the DSL is quite awkward in vanilla JS:

ViewView.content = function(msg) {
  var self = this;
  return self.div({"class": "floobits overlay from-top"}, function(){
    return self.div(msg, {"class": "message"});
  });
};

I suppose this could be an async.waterfall, or we can just avoid the DSL…


#4

Good to know. I’m going to file an issue for this. There’s a ton to do but this is definitely a reasonable request that I’d like to provide a solution for.


Views in a package without coffee script?
#5

I prefer to write my plugin in Vanilla JS as well, so it would be most appreciated if we could extend the View without having the use CS’s version of inheritance (the __extends function). I find it odd that this incompatibility has not been addressed yet. See here for VanillaJS solution (although, it’s rather disgusting): https://gist.github.com/badsyntax/9830697

Where is this issue being tracked exactly?