Hacker News Reader

Comment by tcard | Hacker News Reader

A face-washed JavaScript with classes, interfaces and such stuff. I was expecting something more syntactically close to Go, or at least to Python.

View on HN

Meanwhile, I've been slowly eliminating my usage of `class` from all of my CoffeeScript code. I've found that my code is much more reusable, far less prone to `this` bugs, easier to reason about, etc. I used to be a huuuge OOP guy, but now I rarely find a use for classes...

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.

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`

    > 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: ->
        ...

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.

there are performance reasons for that choice, the prototypal inheritance + constructors are way faster than anything else at the moment

I use classes in Coffeescript, but avoid 'this' bugs by knowing that:

- JQuery examples like to abuse 'this'.

- I should always, explictly provide the event as a parameter in the callback.

So '@' is always the object, and 'event' is whatever started the method.

I have used `class` less and less in my Python code, and when I still use it, it is as little more than a struct.

I never use inheritance.

Since I started to do this, my code has become much simpler and cleaner.

Reply on news.ycombinator.com