Separate methods can be decorated. Which raises the question whether the
proposal is compatible with decorators in their current state.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sat, Oct 24, 2015 at 8:00 PM, Sebastian McKenzie
wrote:
> 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() {
>
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();
}
}
On second thought, a construct method wouldn't add anything that classes don't
do better. Let's just stick with call:
```javascript
class SubFunction extends Function {
someState = {}
// Assigned as internal [[Call]] property.
[Symbol.functionCall]() {
// ...
}
someMethod() {
Why not check `new.target`?
```javascript
function SubFunction() {
// function call
if (new.target === undefined) {
}
// constructor call
else {
}
}
```
On Sat, Oct 24, 2015 at 5:07 PM, Nelo Mitranim wrote:
> On second thought, a construct method wouldn't add
Perhaps you would be interested in the current proposal for Call
Constructors
https://github.com/tc39/ecma262/blob/master/workingdocs/callconstructor.md ?
On Sat, Oct 24, 2015 at 3:39 PM, Nelo Mitranim wrote:
> Separate methods can be decorated. Which raises the question
I've been looking at the Gamepad API. It's a nice API, and the scope is
sensibly narrow, but I think it is just too limited.
With smart TVs, games consoles, Android boxes and so on, lots of users
are using joypads and remote controls to browse the Web. It's pretty
clumsy, but when you only want
7 matches
Mail list logo