/#!/JoePea wrote:
Why can't `super` simply be a shortcut
for "look up the prototype of the object that the method is called on, then
find the `.constructor` property and call it on `this`"? That seems to be
simple.
Simple, yes, and broken in the case of multi-level inheritance:
```
const x =
Regarding the second example, [this resource](
http://exploringjs.com/es6/ch_oop-besides-classes.html#_caveat-objectassign-doesnt-work-well-for-moving-methods)
explains why `Object.assign` doesn't work as expected.
I believe the VM should be smarter than that, and let end-developers use
any
For example, both of these examples don't work in Chrome:
```js
function A() {
console.log('A')
}
A.prototype.constructor = A
A.prototype.hello = function() {
return 'hello'
}
function B() {
console.log('B')
// super()
A.call(this)
}
B.prototype = Object.create(A.prototype)
> On Jul 18, 2016, at 7:04 AM, Jon Coppeard wrote:
>
> On 15/07/2016 18:36, Allen Wirfs-Brock wrote:
>
>>
>
>> ModuleDeclarationInstantiation is a semantics of the ES spec. and it
>> isn’t clear to me why the HTML spec. would need to invoke it.
>
> The HTML spec needs
OK, this is great and I think it solves the problems of what to throw
away and not throwing away too much.
> Implementing this efficiently means
> tracking, for each module, "all the stuff that's depending/waiting on
> me". But the loader has to do this anyway, right?
Yes, this already has to
On 15/07/2016 18:36, Allen Wirfs-Brock wrote:
> Can you point me at the parts of the HTML spec. that involved here?
The script tag is defined here:
https://html.spec.whatwg.org/multipage/scripting.html#the-script-element
The mechanism for loading modules starts here:
What about TypeScript and Flow? They look like the natural candidates here:
already implemented, with real-world projects, tools, and growing
communities. Shouldn't the efforts be put on TypeScript/Flow
convergence/standardization rather than on a new proposal from scratch.
7 matches
Mail list logo