Re: The `super` keyword doesn't work as it should?

2017-10-21 Thread /#!/JoePea
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

Re: The `super` keyword doesn't work as it should?

2016-08-02 Thread /#!/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.

Re: The `super` keyword doesn't work as it should?

2016-08-01 Thread /#!/JoePea
> 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 -

Re: The `super` keyword doesn't work as it should?

2016-08-01 Thread /#!/JoePea
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

Re: The `super` keyword doesn't work as it should?

2016-08-01 Thread Andrea Giammarchi
> 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

Re: The `super` keyword doesn't work as it should?

2016-08-01 Thread 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

Re: The `super` keyword doesn't work as it should?

2016-08-01 Thread /#!/JoePea
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

Re: The `super` keyword doesn't work as it should?

2016-07-30 Thread /#!/JoePea
> 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

Re: The `super` keyword doesn't work as it should?

2016-07-27 Thread Jordan Harband
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

Re: The `super` keyword doesn't work as it should?

2016-07-27 Thread /#!/JoePea
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: >

Re: The `super` keyword doesn't work as it should?

2016-07-27 Thread /#!/JoePea
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

Re: The `super` keyword doesn't work as it should?

2016-07-27 Thread /#!/JoePea
> 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

Re: The `super` keyword doesn't work as it should?

2016-07-27 Thread /#!/JoePea
> 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

Re: The `super` keyword doesn't work as it should?

2016-07-24 Thread Allen Wirfs-Brock
> 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 >

Re: The `super` keyword doesn't work as it should?

2016-07-24 Thread /#!/JoePea
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`

Re: The `super` keyword doesn't work as it should?

2016-07-21 Thread Claude Pache
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

Re: The `super` keyword doesn't work as it should?

2016-07-21 Thread medikoo
/#!/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

Re: The `super` keyword doesn't work as it should?

2016-07-20 Thread /#!/JoePea
@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

Re: The `super` keyword doesn't work as it should?

2016-07-20 Thread Logan Smyth
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

Re: The `super` keyword doesn't work as it should?

2016-07-20 Thread Andrea Giammarchi
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 =

Re: The `super` keyword doesn't work as it should?

2016-07-20 Thread medikoo
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:

Re: The `super` keyword doesn't work as it should?

2016-07-20 Thread /#!/JoePea
> 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

The `super` keyword doesn't work as it should?

2016-07-20 Thread Raul-Sebastian Mihăilă
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

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread Bergi
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

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread Allen Wirfs-Brock
> 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

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread Raul-Sebastian Mihăilă
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

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread Logan Smyth
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;

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread Andrea Giammarchi
`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

Re: The `super` keyword doesn't work as it should?

2016-07-19 Thread /#!/JoePea
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"](

Re: The `super` keyword doesn't work as it should?

2016-07-18 Thread Bergi
/#!/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 =

Re: The `super` keyword doesn't work as it should?

2016-07-18 Thread /#!/JoePea
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

The `super` keyword doesn't work as it should?

2016-07-18 Thread /#!/JoePea
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)