¿Por qué coffeescript genera clases como esta?

Question

Dado el siguiente código CoffeeScript:

class Animal 
    constructor: (@name) -> 
    speak: (things) -> "My name is #{@name} and I like #{things}" 

Esto se genera:

var Animal = (function() { 
    function Animal(name) { 
    this.name = name; 
    } 
    Animal.prototype.speak = function(things) { 
    return "My name is " + this.name + " and I like " + things; 
    }; 
    return Animal; 
})(); 

Pero por qué no se genera el código más idiomática?

var Animal = function Animal(name) { 
    this.name = name; 
}; 
Animal.prototype.speak = function(things) { 
    return "My name is " + this.name + " and I like " + things; 
}; 

sé que CoffeeScript envuelve un montón de cosas en funciones anónimas para controlar la fuga de su alcance, pero lo que pueda haber fugas de aquí?

Answer 1

El código generado hace posible tener funciones nombradas de manera confiable en Internet Explorer. (En este caso, "Animal"). Si simplemente usa una función nombrada en el ámbito de nivel superior, entrará en conflicto con cualquier declaración var Animal = que pueda estar presente ... incluso en ámbitos inferiores, lo que impide que se haga referencia a ellos correctamente. Para evitar el error de IE, incluimos el contenedor de funciones alrededor de la definición de la clase.

Answer 2

Esto es para admitir backtraces que incluyen los nombres de las clases y no solo los nombres de las funciones cuando se lanza una excepción.

Answer 3

El método CoffeeScript también tiene ventajas para la minificación.

De my other answer:

Para la mayoría de las clases razonables, el cierre generada por CoffeeScript genera más pequeño de salida miniaturizada. La envoltura de cierre es de 25 bytes de sobrecarga minified, pero le ahorra de repetir el nombre de clase, ahorrando k * N bytes (k = letras en-nombre, N = num-de-refs). por ejemplo, si una clase como BoilerPlateThingyFactory tiene más de 2 métodos, la envoltura de cierre genera un código minúsculo más pequeño.

---

con más detalle ...

El café Código generado por el uso de un cierre le resta a:

// Uglify '1.js' = 138 bytes (197 w/ whitespace): 

var Animal=function(){function e(e){this.name=e}return e.prototype.speak=function(e){return"My name is "+this.name+" and I like "+e},e}(); 

// with whitespace ("uglifyjs -b"): 

var Animal = function() { 
    function e(e) { 
     this.name = e; 
    } 
    return e.prototype.speak = function(e) { 
     return "My name is " + this.name + " and I like " + e; 
    }, e; 
}(); 

alternativas de ryeguy "idiomáticas" le resta de aplicación a este :

// Uglify '2.js' = 119 bytes (150 w/ whitespace): 

var Animal=function(t){this.name=t};Animal.prototype.speak=function(e){return"My name is "+this.name+" and I like "+e}; 

// with whitespace ("uglifyjs -b"): 

var Animal = function(t) { 
    this.name = t; 
}; 

Animal.prototype.speak = function(e) { 
    return "My name is " + this.name + " and I like " + e; 
}; 

Observe cómo el nombre "Animal" existe exactamente una vez en la forma de café, y N = 2 veces en la varient "idiomática" de ryeguy. Ahora "Animal" solo tiene 6 letras, y solo hay 1 método, por lo que Coffee aquí debería perder entre 25-6 = 19 bytes. Consultando mi código minificado, es de 138 bytes a 119 bytes, para un delta de ... 19 bytes. Agregue 4 métodos más, y la ventaja cambiará a Café. Y no son solo métodos; las constantes de clase y otros tipos de ref cuentan también.