Fat Arrows and Classes-as-Prototype-sugar make a beautiful future for JavaScript

device.js

var stream = require("fake-stream-lib"),
    Emitter = require("events").EventEmitter,
    util = require("util");


// Today...

function Device( opts ) {

  this.value = null;

  // open an async stream,
  // this will be called continuously
  stream.read( opts.path, function( data ) {

    // Update this instance's current value
    // with the most recent value from the
    // data stream
    this.value = data;

  // bind(this) is required for correct scope
  }.bind(this) );

  // Throttle the frequency of events emitted from
  // this Device instance
  setInterval(function() {

    // Emit a throttled event
    this.emit("event");

  // bind(this) is required for correct scope
  }.bind(this), opts.freq || 100 );
}

util.inherits( Device, Emitter );

Device.prototype.scale = function( low, high ) {
  return this.value * ( high - low ) / 1023 + low;
};


// ------------------------------------------------------ //

// w/ Fat Arrow...

function Device( opts ) {

  this.value = null;

  // open an async stream,
  // this will be called continuously
  stream.read( opts.path, ( data ) => {

    // Update this instance's current value
    // with the most recent value from the
    // data stream
    this.value = data;

  // bind(this) is no longer required
  });

  // Throttle the frequency of events emitted from
  // this Device instance
  setInterval(() => {

    // Emit a throttled event
    this.emit("event");

  // bind(this) is no longer required
  }, opts.freq || 100 );
}

util.inherits( Device, Emitter );

Device.prototype.scale = function( low, high ) {
  return this.value * ( high - low ) / 1023 + low;
};



// ------------------------------------------------------ //

// w/ Fat Arrow & Class...


class Device extends Emitter {

  constructor( opts ) {

    super();

    this.value = null;

    // open an async stream,
    // this will be called continuously

    // This example uses the expression
    // form of a fat arrow
    stream.read( opts.path, data => this.value = data );

    // Throttle the frequency of events emitted from
    // this Device instance
    setInterval(() => {

      // Emit a throttled event
      this.emit("event");

    }, opts.freq || 100 );
  }

  scale( low, high ) {
    return this.value * ( high - low ) / 1023 + low;
  }
}

I can live with function for methods. It's the nesting of functions inside methods that becomes noisy. Thin arrows make sense for consistency.

@juandopazo I can see some potential for confusion. I'd like to be able to use the arrow syntax when adding prototype methods, but there's a pretty big gotcha when doing that as it stands. It's a case for either making => soft binding (losing this when called against an object (or with apply, call, or bind)), or ->.

Or going the python route and exposing the original function somehow (boundmethod.im_func is how they do it); though I'd rather fix the problem in a more javascript-y way.

agree 100%

…

On Thu, May 10, 2012 at 11:14 AM, Chris Dickinson < ***@***.*** > wrote: @juandopazo I can see some potential for confusion. I'd like to be able to use the arrow syntax when adding prototype methods, but there's a pretty big gotcha when doing that as it stands. It's a case for either making `=>` soft binding (losing `this` when called against an object (or with `apply`, `call`, or `bind`)), or `->`. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2654256

I'm afraid soft bind will just never happen. I've argued against it for programming reasons, but it doesn't even really matter; the fact is it can't be implemented without making every call in the entire language more expensive. That would make the whole web slower, and JS engine implementers won't do it.

Dave

<3

Re: thin arrows for methods. An alternative that has come up is using method shorthand in combination with the .{ operator:

Device.prototype.{
  scale( low, high ) {
    return this.value * ( high - low ) / 1023 + low;
  }
};

This has the added benefit (in the current TC39-approved status quo) that methods created using method shorthand get access to super. But, I believe as of last count .{ is not TC39-approved.

I'm warming up to classes. The rest I'm still not crazy about.

Omg, no fat arrows please!! On non-English keyboards the equals sign is often a character requiring shift to type. Thin arrow is better in that respect.

this is an excellent point. Marc

…

On May 13, 2012, at 5:51, Marc ***@***.*** wrote: Omg, no fat arrows please!! On non-English keyboards the equals sign is often a character requiring shift to type. Thin arrow is better in that respect. --- Reply to this email directly or view it on GitHub: https://gist.github.com/2654256

And English keyboard require shift for " which I'm sure it's written more often than function or =.

Non-English keyboard usually suck for coding anyway. Spanish-Spain keyboard requires Alt-Gr for both types of brackets. Alt-Gr! Fortunately there's the Latinamerican keyboard that looks a little more like the English one.