Duplicate super call behaviour
I was recently reading the specification on the behaviour of duplicate
super() calls in derived constructors. Reading the grammar the following is
valid:
```
class Foo {
constructor() {
console.log("foobar);
}
}
class Bar extends Foo {
constructor() {
super();
super();
}
}
new Bar;
```
However my reading of the runtime semantics, it will actually execute the
constructor body *twice. *And so "foo" will be printed two times.
This is because the only thing I've found stopping duplicate super calls is
step 10 of SuperCall in 12.3.5.1
:
1. Let newTarget be GetNewTarget().
2. If newTarget is undefined, throw a ReferenceError exception.
3. Let func be GetSuperConstructor().
4. ReturnIfAbrupt(func).
5. Let argList be ArgumentListEvaluation of Arguments.
6. ReturnIfAbrupt(argList).
7. Let result be Construct(func, argList, newTarget).
8. ReturnIfAbrupt(result).
9. Let thisER be GetThisEnvironment( ).
10. Return thisER.BindThisValue(result).
Since BindThisValue will throw a ReferenceError if `this` has already been
initialised:
1. Let envRec be the function Environment Record for which the method
was invoked.
2. Assert: envRec.[[thisBindingStatus]] is not "lexical".
3. If envRec.[[thisBindingStatus]] is "initialized", throw a
ReferenceError exception.
But this check is performed at step 10 whereas the super constructor is
actually evaluated at step 7.
Is my reading correct? If so, to me this behaviour seems quite unexpected.
Any insight (or correction) is extremely appreciated, thank you!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Aliased object destructuring assignments?
The syntax is indeed invalid, but syntax does exist to do the equivalent:
```javascript
var { f: foo } = someObject;
```
On Mon, Jun 22, 2015 at 1:50 AM, Salehen Rahman salehen.rah...@gmail.com
wrote:
I know that `import` allows us to alias imports, like so:
```javascript
import { f as foo } from 'f';
```
But what about object destructuring assignments?
```javascript
var { f as foo } = someObject; // Syntax error on Babel
```
Either Babel is very late in the game, or the above syntax is actually not
supported in ECMAScript.
It would be really beneficial to support aliasing for object destructuring.
I find it would make sense since array destructuring assignments allow us
to assign values to arbitrary variable names.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Example of real world usage of function bind syntax
In Babel all the experimental features are behind flags and the docs (http://babeljs.io/docs/usage/experimental/) are very explicit about their status: Subject to change These proposals are subject to change so use with extreme caution. Babel may update without warning in order to track spec changes. Even the blog posts announcing new features (http://babeljs.io/blog/2015/05/14/function-bind/) have warnings at the top: Warning: This syntax is highly experimental and you should not use it for anything serious (yet). If you do use this syntax, please provide feedback on GitHub. So I’m curious to hear what suggestions you have to make this clearer. On Thu, Jun 11, 2015 at 4:19 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: not arguing or anything, and just as parenthesis, but this: On Thu, Jun 11, 2015 at 4:31 PM, Kevin Smith zenpars...@gmail.com wrote: Not sure you should use it in production, just yet... is what I keep seeing as pattern: 1. here: please try this but don't use in production since not standard (see transpilers early adoption, __proto__, etc) 2. ... developers write code regardless ... 3. too late to drop that since it's already in production out there I wish Babel or any other transpilers warned in red everything that does not come from standards, reminding that things could and probably will change, so that it's clear developers can test at home but not deploy (unless they truly know what they are doing or they are OK risking changes). Please don't get me wrong, I do like the :: proposal but the way it's going out, I'm not sure is the best we can do as TC39/developers collaboration. Best Regards___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Example of real world usage of function bind syntax
Not really. It would require something like Recast (https://github.com/benjamn/recast) to do nondescructive pretty printing to retain as much of the source formatting as possible. This shouldn’t be necessary though as if you’re using these experimental features extensively enough in production apps to justify the existence of a transpiler for dead experimental features then you’ve already committed a sin. On Thu, Jun 11, 2015 at 4:32 PM, Matthew Robb matthewwr...@gmail.com wrote: @Sebastian It would be interesting to explore having a defined method of deprecation for features. Basically say this bind syntax is being dropped, I'd like Babel to be able to transpile all of my SOURCE files to remove it's usage. Has anything like this been discussed before? - Matthew Robb On Thu, Jun 11, 2015 at 11:28 AM, Domenic Denicola d...@domenic.me wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb I would be significantly less excited about it if this happens. The ability to pass around lightly bound references to methods is a big deal imo and a large part of the value in this proposal. Definitely agree. Being able to do `foo.map(::this.bar)` is really great, and even `const extracted = ::foo.bar` is nothing to sneeze at. I know there's a thread on the issue tracker where a few vocal voices are complaining that they want partial application syntax and bikeshedding on various operator forms related to that, but I don't think that should discourage the excellent benefits that you're giving to everyone but those few. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
This is a limitation of Babel and not at all a reflection of the actual specification. This restriction is imposed order to follow ES2015 semantics of not being able to reference `this` before `super()`. It does a pretty dumb check of only allowing it to be strictly after the call (ie. not before or inside it). Note that this is also the behaviour of Traceur and TypeScript so Babel is not alone with this decision. You can see extensive discussion of this in the issue: https://github.com/babel/babel/issues/1131 On Tue, Jun 2, 2015 at 11:36 PM, Matthew Robb matthewwr...@gmail.com wrote: I was trying to demonstrate a simple method of exposing resolve and reject functions to someone and noticed in Babel at least you cannot do this. It seems as though in this case when the arrow function is called it will have been AFTER the call to super. Can someone help me understand what's going on here? - Matthew Robb___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise sub-class: super((resolve, reject) = this) ?
Ah, completely right. At first glance I thought it was this similar but
separate issue:
```js
class Foo {
constructor(callback) {
this.callback = callback; // just storing it!
}
}
class Bar extends Foo {
constructor() {
super(() = this); // reference to `this` will throw since the behaviour of
the super class can’t be easily inferred
}
}
```
Shifting runtime errors to compile time isn’t always the most reliable.
On Tue, Jun 2, 2015 at 11:43 PM, Domenic Denicola d...@domenic.me wrote:
Hmm I am pretty sure Babel et al. are correct here in not allowing this. The
super call needs to *finish* before you can use `this`. Chrome also works
this way.
The correct workaround is
```js
let resolve, reject;
super((a, b) = {
resolve = a;
reject = b;
});
// use this
```___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Label statement moveable
So you want to add goto to JavaScript?
On Wed, May 20, 2015 at 11:42 AM, Emanuel Allen emanuelal...@hotmail.com
wrote:
Clarify:
My previous post was not that clear. That post display what I would like to
do in the language. Here is the actual code if I choose to do it as the
language is now:
var i = 0, n = 5;
l2: do {
i += 1;
l3: do {
if (in) continue l2;
else break l3;
} while (true);
break l2;
} while (true);
//just log the value n+1:
console.log('i:'+i);
loop through label l2 n amount of times before breaking.
This could be useful to escape function invocation cost, if it could be
simply express:
l2: {
i += 1;
}
l3: {
if (in) continue l2;
}
The function way is to:
function l2(){
i += 1;
}
l3: do {
if (in) l2();
else break l3;
} while (true);
I did a a href=http://jsperf.com/block-scope-vs-function-invocation;
jsprf /ato further my argument for a sudo goto/function effect:
http://jsperf.com/block-scope-vs-function-invocation
JS4Lf
On May 19, 2015, at 2:45 PM, L4L lv2lrn...@gmail.com wrote:
Since we have block scope, and we have continue statement to which we can
use in loops to jump back to the conduction statement part.
Than can we consider making label stamens moveable by its name.
I'll like to say that the side effect would be sudo(pseudo) function,
example:
function foo(v){
return v + 1;
}
var i = 0;
baz:{
i += 1;
}
continue baz;//same as foo(i);
console.log(i);
Note that I said sudo function. Its mobility is what of value; depending on
how JavaScript handle the continue statement in a loop to transport that
effect out side a loop.
Stripping this privilege to black scope; where the continue statement is
expanded to work only in block scope and nested block scope; to where it can
only jump to the beginning of that block or any other block scope that is
scoped to that outer block scope but not nested block scope with in the
scope... Like function.
Continue and break statement could be of more power; where we can avoid some
function call in speed matter application.
Excuse any grammar errors.
JS4Lf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Non-binding destructuring assignment
The binding identifiers are optional. You can do what you want already with:
const lastOfThree = ([,, third]) = {
return third;
}
On Wed, Apr 29, 2015 at 12:40 PM, Elie Rotenberg e...@rotenberg.io
wrote:
Using array destructuring assignment and constraining linting rules, I
often find myself having to chose names for bindings I don't intent on
using. I usually end up using a conventional ignore name, such as _ignore,
which I void to shut up the linter without adding exceptions. Besides the
linting problem (which can be solved by refining the linting rules), it's
still a conceptually useless binding.
Here's a contrived example:
const lastOfThree = ([first, second, third]) = third;
Which I usually end up rewriting:
const lastOfThree = ([_ignore1, _ignore2, third]) = {
void _ignore1;
void _ignore2;
return third;
}
This problem doesn't exist when using objects, since only the fields
specified on the LHS are bound.
I realize the bigger topic behind non-binding match is refutable pattern
matching, as per
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching, but being
able to dismiss a matched (or unmatched) value from a destructuring
assignment seems a very often desirable feature when programming in a
functional style (eg. working with lists represented as 2-element arrays).
Most functional-style languages have a non-binding matching feature.
This topic has been discussed in the following topics:
- https://esdiscuss.org/topic/conditional-catch
- https://esdiscuss.org/notes/2014-07-30
- https://esdiscuss.org/topic/conditional-catch-clause
Does anyone else feel the need for a specific means of dismissing a binding
from a destructuring assignment? Is pattern matching still on discussion?
Regards,___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Trailing commas in arguments list, imports and destructuring
Note that you’ve got the experimental REPL option enabled which means all
transformers are enabled which includes the `es7.trailingFunctionCommas` one
which allows trailing commas in function parameter lists and call expressions.
The destructuring grammar does allow trailing commas
(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns):
ObjectBindingPattern[Yield,GeneratorParameter] :
{ BindingPropertyList[?Yield,?GeneratorParameter] , }
ArrayBindingPattern[Yield,GeneratorParameter] :
[ BindingElementList[?Yield, ?GeneratorParameter] , Elisionopt
BindingRestElement[?Yield, ?GeneratorParameter]opt]
And import specifiers allow trailing commas too
(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
):
NamedImports :
{ ImportsList , }
On Wed, Apr 22, 2015 at 4:16 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I just noticed that Babel support trailing commas in function arguments
lists, imports and destructuring as well:
http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x%2C%0A%20%20y%2C%0A%7D%20%3D%20voo%3B%0A%0Alet%20%5B%0A%20%20z%2C%0A%20%20m%2C%0A%5D%20%3D%20doo%3B%0A%0Afunction%20qoo%20(%0A%20%20x%2C%0A%20%20y%2C%0A)%20%7B%7D
Is this correct behavior? I'm not
FWIW as I already use trailing commas object and array literals for better
diffs, I really like this feature as it comes in handy especially in
function signatures where you define types (TypeScript/flow style
annotations), for example:
function sort T (
array : ArrayT,
compareFn : ((left: T, right: T) = number),
) : ArrayT {
...
}
as well as import statements for modules that declare constants:
import {
BRAND_COLOR,
DEFAULT_TEXT_COLOR,
DARK_GRAY,
LIGHT_GRAY,
} from ./constants/COLORS;
not to mention options object style function signatures:
class Person {
constructor ({
firstName,
lastName,
birthDate,
country,
city,
zipCode,
}) {
this.firstName = firstName;
this.lastName = lastName;
this.birthDate = birthDate;
this.country = country;
this.city = city;
this.zipCode = zipCode;
}
}
To me, the spec language as per Jason's HTML version looks like at least
for destructuring this is supported, but at least I can't read the spec to
allow trailing commas in function signatures. At least this doesn't seem to
be incorporated into the spec:
https://esdiscuss.org/notes/2014-09/trailing_comma_proposal.pdf
Is the proposal still on track for ES7 and am I correct in my reading of
the destructuring allowing trailing commas?___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: super() on class that extends
Babel is a terrible reference implementation for subclassing since it relies on
the engine. See the docs http://babeljs.io/docs/usage/caveats/#classes and
https://github.com/babel/babel/issues/1172 for more info. This exact question
(super in derived class constructors) was also indirectly bought up recently in
this issue: https://github.com/babel/babel/issues/1131
On Fri, Apr 10, 2015 at 6:57 PM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
On 4/10/15, Axel Rauschmayer a...@rauschma.de wrote:
The reason why you need to call the super-constructor from a derived class
constructor is due to where ES6 allocates instances - they are allocated
by/in the base class (this is necessary so that constructors can be
subclassed that have exotic instances, e.g. `Array`):
Can you please explain how extending Array works. Also what is the
optional identifier optional for in ClassExpression:
var myArray = (new class B extends Array {
constructor() {
super(1,2,3,4,5);
}
});
alert(myArray.length); // it's 0 in Babel.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
personx.tumblr.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential Operator / Null Propagation Operator
No, you’d just memoise it to a variable:
a?.d().f?.b
to:
var _temp, _temp2;
(a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined
? _temp2.b : undefined) : undefined)));
You’re going to need to memoise all member expressions anyway as they might be
accessing a getter and you don’t want to call it twice.
On Tue, Apr 7, 2015 at 7:32 PM, joe joe...@gmail.com wrote:
Okay. I've updated my transpiler to demonstrate how (and why) this could
work at the VM level (I do think VM devs will have to add new opcodes for
this), and I've appended an example transformation to this email.
Why is this so complicationed? The answer is that when you start nesting
?. operators, it's pretty easy to cause some operators to be called twice.
E.g, if you transformed the following to the NULL syntax:
a?.d().f?.b
You would get:
(a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b
: undefined) : undefined)));
Notice how a.d() gets called multiple times.
The solution is probably new VM opcodes. Since my transpiler is obviously
not a VM, it transforms ?. operators into auto-generated functions.
Anyway, here's the example I transpiler:
a?.b.c.e?.f.g?.h.t.c?.d()?.e;
Which turned into this:
function q0eILlfx7_3(obj) {
var _t=obj;
if (_t==undefined)
return undefined;
_t = _t.b.c.e;
if (_t==undefined)
return undefined;
_t = _t.f.g;
if (_t==undefined)
return undefined;
_t = _t.h.t.c;
if (_t==undefined)
return undefined;
_t = _t.d();
return _t;
}
q0eILlfx7_3(a);
On Tue, Apr 7, 2015 at 6:24 PM, Brendan Eich bren...@mozilla.org wrote:
joe wrote:
That's a good point. Are lexical non-DFA grammars allowed? It would be
trivial to solve that with a regular expression lookahead. Although I
suppose at that point you might as well call it a cover grammar.
We must avoid being too clever -- it complicates implementations and
inevitably incurs future-hostility to extensions we may want, if not
outright bugginess.
All of this suggests prefix ? is the better course. Anyone have
counterexamples?
/be
Joe
On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
joe wrote:
By the way, I don't remember having grammar issues (I use a
LALR compiler-compiler). Looking at my code, it looked like I
handled it in the tokenizer stage; I added a COND_DOT token:
COND_DOT : \?\.
Did you keep backward compatibility? `x?.1:y` must continue to work.
/be
No, it looks like I didn't.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 95, Issue 45
Reason for the verbose and quirky output in 6to5 is due to performance, see https://github.com/6to5/6to5/pull/203 On Tue, Jan 20, 2015 at 11:45 PM, Fabrício Matté ultco...@gmail.com wrote: Point 2 is incorrect (e.g. `new (Foo.bind.apply(Foo, [undefined].concat(args)))`). I stand corrected. That's very good news, thanks! Nice and elegant solution, by the way. I should have taken the time to look at how current transpilers handle that. Your solution is similar to Traceur's generated output, but it is also interesting to see how [6to5 spreads arguments in a NewExpression]( http://6to5.org/repl/#?experimental=trueplayground=trueevaluate=trueloose=falsecode=class%20Foo%20%7B%7D%0Avar%20arr%20%3D%20%5B%5D%3B%0Anew%20Foo(...arr)%3B ). Oh, I also had a typo in the previous mail (`s/rest parameters/spread`), guess I was a bit too sleepy last night. /fm___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Overriding the == operator, like in Java/Lua/Python/whatever.
http://www.slideshare.net/BrendanEich/value-objects2 On Sun, Jan 4, 2015 at 1:08 PM, Caitlin Potter caitpotte...@gmail.com wrote: Unfortunately, there's no real way to do this as of yet, short of abusing ToPrimitive in certain cases, far from ideal. I'm sure someone must have proposed it at some point, but perhaps not. In the mean time, it might be a nice feature of a compile-to-js language like coffeescript or typescript to experiment with On Jan 3, 2015, at 8:52 PM, Soni L. fakedme...@gmail.com wrote: I've been looking and looking and looking and I couldn't find a way to override == to make 2 different instances of MyPoint compare == if they have the same coordinates. (I guess this also applies to String objects and stuff but I haven't tested that) So how do I do this? (PS: yes, I know, Java has an .equals method, not overridable ==, but it's basically the same thing) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard modules?
It seem strangely inconsistent not to make it a global. I've had to access
GeneratorFunction using the aforementioned method when I was writing an
async view engine to dynamically create rendering functions like so:
var GeneratorFunction = (function *() {}).constructor;
var functionBody = ;
// parse view
return new GeneratorFunction(functionBody);
Accessing it via the constructor seems very sloppy.
On Tue, Jan 21, 2014 at 4:39 AM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
It isn't clear that there much need for a global name for
GeneratorFunction. If you really eed to access it can always get it via:
(function *() {}).constructor
Does this present a hazard for CSP, which provides policy controls
governing Function?
I agree we shouldn't add a global GeneratorFunction -- not without a
pressing use-case and evidence that we can get away with adding that global.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sebastian McKenzie
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
