I hope you're not using `Object.assign` to copy anything different from basic setup-like or arguments objects: if I were you I would use `Object.defineProperties(targetProto, Object.getOwnPropertyDescriptors(superProto))` or it gonna be "bad time".
I think they answered already on the dynamic super, not sure keep raising the issue would help :-( Best Regards On Wed, Jul 27, 2016 at 8:13 PM, /#!/JoePea <[email protected]> wrote: > > IIRC methods shorthand are the only where super is allowed, at least in > Chrome and Firefox. > > If `super` were dynamic, then `super` could be allowed anywhere, not just > in Classes or object-initializer shorthand methods. > > For what it's worth, `Object.assign` is a concept promoted into the > language by pre-ES6 ideas, like underscore's `_.extend` and others. So, the > mere fact that `Object.assign` will fail to produce expected results when > copying something from an ES6 prototype that uses `super` means that the > direction of the ES6+ language is backwards-incompatible with pre-ES6 > JavaScript and that ES6+ features are incompatible with themselves. > > If something like `Function.prototype.toMethod` made it into spec but not > a dynamic `super`, then solution would be half-complete: tools like > `Object.assign` would also need to start using `toMethod` internally so > that results would be intuitive. > > Arguably, the best solution would be for `super` to be dynamic and for > `Function.prototype.toMethod` to exist, following the same patterns as we > *love* about JavaScript's `this` keyword. This would open up > meta-programming possibilities, for example it would then be easy to write > a [prototype-based implementation of multiple inheritance]( > https://gist.github.com/trusktr/8c515f7bd7436e09a4baa7a63cd7cc37) whereby > a single prototype chain is created based on the multiple classes we wish > to extend from (this is in constrast to a [`Proxy`-based implementation]( > https://gist.github.com/trusktr/05b9c763ac70d7086fe3a08c2c4fb4bf)). > > Claude Pache [mentioned that he likes for method borrowing to maintain the > same HomeObject]( > https://esdiscuss.org/topic/the-super-keyword-doesnt-work-as-it-should#content-16), > but in my opinion that does not stay inline intuitive expectations coming > from pre-ES6 with a dynamic `this`: "I intuitively expect super to be > relative to the prototype chain of the current object where a method is > called". > > If you are technical enough to understand why method borrowing fails due > to a static `super`, then you'd also be technical enough to understand why > it works the dynamic way if that ever became reality. Plus, if > `Function.prototype.toMethod` is brought into spec, then you'd also be > technical enough to borrow the method and assign the original HomeObject > that you wish. > > */#!/*JoePea > > On Wed, Jul 27, 2016 at 11:44 AM, /#!/JoePea <[email protected]> wrote: > >> What's the good reason that object-initializer methods can't be >> constructors though? I mean, I get that "that's what spec says", but what's >> the actual good reason? >> >> The problem here would be solved with a dynamic super. >> >> I feel that ES6 diverges from ES5 in backwards-incompatible ways. Some >> people say ES6 classes are "syntax sugar" over the ES5 constructor pattern >> classes, but, *not really*, since they aren't compatible in the same >> places. ES6 classes and object-initializer methods are not >> backwards-incompatible in a bad way because they cannot be treated the same >> as we are used to in ES5 (f.e. copying methods with underscore's >> `_.extend()` doesn't work because of static HomeObjects), and that is >> backwards-incompatible with previous concepts, ideas, and methodologies >> that we love JavaScript for. >> >> Some old code might do something like >> >> ```js >> _.extend(SomeClass.prototype, OtherClass.prototype) >> ``` >> >> where `SomeClass` and `OtherClass` are ES5 constructor-pattern classes. >> If the classes are updated to be ES6 classes, then that code may fail >> because of the static `HomeObject` properties, and that is >> backwards-incompatible with the paradigms and patterns of ES5. >> >> **A dynamic super would remedy this problem.** >> >> For now, I am contemplating using a custom and dynamic >> `Object.prototype.super` getter in all apps where my code runs so that my >> ES6 classes remain as flexible as in ES5. The overhead associated with a >> custom `Object.prototype.super` would only be due to the fact that it is >> not possible for us to hook into the native property lookup algorithm, >> otherwise the overhead of finding a HomeObject would be completely >> negligible because the native property lookup algorithm already finds the >> HomeObject where a property or method is located and therefore it would >> cost next to nothing to use the found HomeObject on a method call by >> passing HomeObject as an argument in the native side of the JS engine. >> >> >> */#!/*JoePea >> >> On Wed, Jul 27, 2016 at 7:58 AM, Allen Wirfs-Brock <[email protected] >> > wrote: >> >>> The most common case is the “methods” are designed to be used as >>> constructors. This has always be recognized for built-in methods in the >>> ECMAScript specification which says: "Built-in function objects that are >>> not identified [in this specification] as constructors do not implement the >>> [[Construct]] internal method unless otherwise specified in the description >>> of a particular function.”. When “concise methods” where add as part of >>> Object Initializers and Class Definitinos this default was applied to them. >>> >>> You can still define constructible properties for Object Initializers, >>> just not by using concise method syntax: >>> >>> ```js >>> let classes = { >>> Cat: function() {}, >>> Dog: function() {}, >>> Bird: class {} >>> }; >>> >>> let [c, d, b] = [new classes.Cat, new classes.Dog, new classes.Bird]; >>> ``` >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
