Sep 27 meeting notes

Sam Tobin-Hochstadt samth at ccs.neu.edu
Fri Sep 30 14:22:58 PDT 2011


On Fri, Sep 30, 2011 at 5:11 PM, Claus Reinke <claus.reinke at talk21.com> wrote:
>>> class Point {
>>>  var x = 0;
>>>  var y = 0;
>>>  distance(other) {
>>>   return Math.sqrt(x * other.x + y * other.y);
>>>  }
>>> }
>>>
>>> it is very tempting to think that var x and var y are in scope.
>
> Would the following analogy with modules help?

This analogy came up at the recent face-to-face meeting, and I want to
disagree with it here too, at least if your analogizing to ES.next
modules.

>   Think of 'this' as    - the export object of the constructor method
>   - an import object of all methods.

Modules don't have an "export object", or an "import object".  Module
instance objects are values which reflect the exports of a module, but
they aren't the module themselves.  And regardless, the semantics of
modules is not the same as the import and export objects of CommonJS .

> Then one might want nice syntax for moving between local
> bindings and import/export objects, without risks to lexical
> scoping. Which is the same problem modules have, isn't it?

Modules don't have a problem with this, because they don't have
import/export objects.

> Could one use punning ({x} standing for {x=x}), destructuring, and returning
> 'this'?
>
>   distance(other) {
>       let {x,y} = this;    // import
>       return Math.sqrt(x * other.x + y * other.y);
>   }
>
>   constructor(x,y) {
>       return {x,y};    // export
>   }

First, these aren't like export or import.  Second, we've agreed, I
think, that returning something other than 'this' from class
constructors is a non-goal for ES.next classes, to be revisited for
future harmonizing.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list