4 ms·

Prototypes are fine for a language like JavaScript. They keep things simple. I'd prefer that CoffeeScript (and Dart, of course) implemented a decent syntax for

by tcard 15y ago

Prototypes are fine for a language like JavaScript. They keep things simple. I'd prefer that CoffeeScript (and Dart, of course) implemented a decent syntax for prototyping, replacing the JS mess, rather than trying to disguise them as leaky and half-featured classes.

snprbob86 15y ago
There was a recent article on HN about Self and its prototype patterns. Looked far superior to Javascript's. But even still, prototypes only seem primarily useful if you want member-access as dot-notation or polymorphism by type. When preferring composition over inheritance, most polymorphic-by-type situations either go away or can be trivially replaced with maps. That said, CoffeeScript provides another interesting use for them: Simulating dynamic binding. Basically, the trick is that `this` becomes the dynamic binding context and `@` represents a dynamically bound variable. You use `fn.call @, x, y, etc...` if you want to pass the dynamic binding to callees. Nested bindings can be established with `Object.create`
jashkenas 15y ago
> leaky and half-featured classes. This is a common willful misconception. CoffeeScript classes are isomorphic to JavaScript prototypes -- the do precisely the same thing. In addition, there is a shorthand syntax for prototyping objects, if that's more your style: Dog = -> ... Dog::bark = -> ... Dog::run = -> ... Note that the above will produce the same result as: class Dog bark: -> ... run: -> ...
- tcard 15y ago
  I didn't mean that CoffeeScript classes don't cover prototypes —but the other way around: prototypes can't implement the whole typical class abstraction (encapsulation, etc.). So I think CoffeeScript would do better implementing a completely new syntactic abstraction over prototyping that fix all the JavaScript awkward ambiguities than adapting classes to prototypes. But it's still OK, I like and use CS classes.
  - gryzzly 15y ago
    there are performance reasons for that choice, the prototypal inheritance + constructors are way faster than anything else at the moment

by tcard 15y ago

snprbob86 15y ago

There was a recent article on HN about Self and its prototype patterns. Looked far superior to Javascript's. But even still, prototypes only seem primarily useful if you want member-access as dot-notation or polymorphism by type. When preferring composition over inheritance, most polymorphic-by-type situations either go away or can be trivially replaced with maps. That said, CoffeeScript provides another interesting use for them: Simulating dynamic binding. Basically, the trick is that `this` becomes the dynamic binding context and `@` represents a dynamically bound variable. You use `fn.call @, x, y, etc...` if you want to pass the dynamic binding to callees. Nested bindings can be established with `Object.create`

jashkenas 15y ago

> leaky and half-featured classes. This is a common willful misconception. CoffeeScript classes are isomorphic to JavaScript prototypes -- the do precisely the same thing. In addition, there is a shorthand syntax for prototyping objects, if that's more your style: Dog = -> ... Dog::bark = -> ... Dog::run = -> ... Note that the above will produce the same result as: class Dog bark: -> ... run: -> ...

tcard 15y ago
I didn't mean that CoffeeScript classes don't cover prototypes —but the other way around: prototypes can't implement the whole typical class abstraction (encapsulation, etc.). So I think CoffeeScript would do better implementing a completely new syntactic abstraction over prototyping that fix all the JavaScript awkward ambiguities than adapting classes to prototypes. But it's still OK, I like and use CS classes.
- gryzzly 15y ago
  there are performance reasons for that choice, the prototypal inheritance + constructors are way faster than anything else at the moment