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