Here's a new real-world example showing people are naturally expecting ES6
`super` to be dynamic when they copy methods from objects to other objects:
https://stackoverflow.com/questions/46306598.
It makes sense to assume it would work this way considering how dynamic
pre-ES6 is!
*/#!/*JoePea
Alan, after considering the [March 25th Declarative Alternative to toMethod
conversation](
https://github.com/tc39/tc39-notes/blob/master/es6/2015-03/mar-25.md#6iv-a-declarative-alternative-to-tomethod-allen-wirfs-brock),
it really seems like a dynamic `super` would solve the problems mentioned.
> fn.bind().bind() can't throw because of backward compatibility.
Well, that's fine with me. The important thing to consider would be those
other things I listed that shouldn't throw. These ones:
- `func.bind(...)` does not throw
- `func.toMethod(...)` does not throw
-
Andrea,
> losing getters and setters where super is also allowed is all we *don't*
need as well, not sure why keep ignoring the fact Object.assign has
undesired side-effects.
Right, but that's well-explained (for example, in the MDN docs). It is also
easy to use `getOwnPropertyNames` or
> I'm just re-iterating, but `Object.assign()` is all we need
losing getters and setters where super is also allowed is all we *don't*
need as well, not sure why keep ignoring the fact Object.assign has
undesired side-effects.
On Mon, Aug 1, 2016 at 8:30 AM, Michał Wadas
fn.bind().bind() can't throw because of backward compatibility.
On 1 Aug 2016 9:21 a.m., "/#!/JoePea" wrote:
> Allen, I read your linked documents. After thinking about it more, I
> believe it would be ideal to have both:
>
> 1. a tool like `toMethod`. I like "setHome" better
Allen, I read your linked documents. After thinking about it more, I
believe it would be ideal to have both:
1. a tool like `toMethod`. I like "setHome" better as that describes much
more concisely what is happening. `.bind()` is already a way to make a
function *behave as a method* of the object
> Could you not make `multiple` be a function that returns a Proxy, rather
than achieving multiple inheritance by copying properties?
I thought about that originally, so that instead of copying methods onto
the class that extends from the multiple super classes, I would just look
for the
Could you not make `multiple` be a function that returns a Proxy, rather
than achieving multiple inheritance by copying properties?
On Wed, Jul 27, 2016 at 8:19 PM, /#!/JoePea wrote:
> For reference, here's the implementation of `multiple()` where multiple
> constructors calls
For reference, here's the implementation of `multiple()` where multiple
constructors calls are possible, using a `callSuperConstructor` helper:
https://gist.github.com/trusktr/05b9c763ac70d7086fe3a08c2c4fb4bf
*/#!/*JoePea
On Wed, Jul 27, 2016 at 8:16 PM, /#!/JoePea wrote:
>
For now, I've settled with writing classes like this:
```js
const SomeClassMixin = base => {
class SomeClass extends base {
// ...
}
return SomeClass
}
const SomeClass = SomeClassMixin(class{})
SomeClass.mixin = SomeClassMixin
export {SomeClass as default}
```
This makes
> 1) There are indeed use cases for dynamically configuring the HomeObject
binding but they are quite specialized
I suppose my case is quite specialized. I am wanting to duplicate the
prototype chains of ES6 classes, but I have no reliable (afaik) way to make
the `super` keyword work on copied
> With the current spec, it's risky because this and super basically may
use two different prototype chains
That's horrible, and I think that should be possible only when forced, by
manually using `Function.prototype.toMethod`. Otherwise (with `super` being
dynamic) there should be only a single
> On Jul 24, 2016, at 7:04 PM, /#!/JoePea wrote:
>
> What if there was also something like `Function.prototype.bind` like
> `Function.prototype.with`, so `someFunc.with(homeObject)` returns a new
> function who's [[HomeObject]] is the specified `homeObject`. It would be
>
It doesn't make sense because then `super` isn't really referring to the
super class that the method is used on. I think it makes more sense for
`super` to take meaning depending on where the method is found, not where
it is defined.
What if there was also something like `Function.prototype.bind`
There is probably no way to make the `super` semantics just work in all use
cases. But I think that the choice made in ES6 is the right one in order to
have it correctly working in the most naïve (and maybe the most common?) use
cases of method borrowing, i.e., when you don’t have knowledge of
/#!/JoePea wrote
> Is there any hard evidence of the performance cost of a dynamic super? So
> far I've read in various places (for example the thread linked to by
> @medikoo, Axel's 2ality article on super) about there being "overhead",
> but
> the articles haven't quantified or put into
@medikoo, wow, the conversation has been going on for a long time. And in
that conversation you linked, Sean Eagan said
> I think a static |super| in light of ES's dynamic |this| would
actually be much more surprising. This would lead to looking for
properties in a static |super| object
Joe, yes sorry, my mistake. `a` should have `__proto__: b`, and `b` should
have `__proto__: c` in my example, that's what I get for not validating it
better. Each could `return` but since `a.method` was the only one I called,
it was the only one I put the `return` in.
On Wed, Jul 20, 2016 at 3:27
For implementation sake, this is a quick'n'dirty approach that brings a
dynamically resolved `super` to any object or prototype:
https://gist.github.com/WebReflection/ee4695c107339e039878b02afb90dc0d
Usage example:
```js
function A() {
console.log(this.constructor.name);
}
A.prototype.method =
Joe, see this post:
http://mozilla.6506.n7.nabble.com/Making-quot-super-quot-work-outside-a-literal-td90457.html#a90551
There are some explanations there on why super was implemented as something
/static/ and not /dynamic/
--
View this message in context:
> In this example, `super.method()` will work fine, and `a.method() === 6`
because each super call will reassign `this.prop`, where `this === a`.
Did you mean `c.method() === 6`? Also I'm assuming you meant for `.method`
of `b` and `c` to have return statements too? I also assume you meant to
put
I wasn't suggesting any mechanism for accomplishing that. Method borrowing
is error prone either way. With the current spec, it's risky because this
and super basically may use two different prototype chains. Also you may
change the prototype of the home object and run into trouble. (In the
Raul-Sebastian Mihăilă wrote:
An alternative would be to consider the object where the method key was
found as the home object of the method.
That's just as error-prone, method borrowing would only work when the
two objects had the same superclass.
Also, what about methods that are not
> On Jul 19, 2016, at 11:45 AM, Raul-Sebastian Mihăilă
> wrote:
>
> An alternative would be to consider the object where the method key was found
> as the home object of the method.
that was considered while designing ES6. The problem is that it introduces an
An alternative would be to consider the object where the method key was
found as the home object of the method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Joe, it seems like you've focused on `super ===
Object.getPrototypeOf(this)` as the overall ideal without considering the
issues with it. I've tried to put together a few counterexamples below. Say
you have a base set up like this:
```
var a = {
prop: null,
method(){
this.prop = 4;
`super === Object.getPrototypeOf(this)` also doesn't work with multiple
inheritance.
If interested, it has been solved dynamically in this good'ol library:
https://github.com/WebReflection/es-class#es6-ready
Regards
On Tue, Jul 19, 2016 at 11:03 AM, /#!/JoePea wrote:
> Hi
Hi Bergi, yes, so the object that `super` references would work like
`this`, where the value is determined at runtime instead of in a
declaration. Basically, `super === Object.getPrototypeOf(this)` would
actually be true in my examples. It may be due to ["extra overhead"](
/#!/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)
32 matches
Mail list logo