Thanks for the examples. But I wonder why beat around the bush and not let developers express exactly what they want?
> On Feb 20, 2015, at 5:51 PM, Leon Arnott <[email protected]> wrote: > > Ah, right, my apologies for misreading. > > So... I think this scenario would be better served if ES7 had shorthands for > non-(enumerability|writability|configurability) added to the object literal > syntax, as some in the past have postulated - and a method for copying > non-enumerable (and also symbol-keyed) properties was available. > > ``` > class Foo { ... } > > Object.copyOwnProperties(Foo.prototype, { > noenum bar, /* Assigns 'bar' to the object, making it non-enumerable and > non-writable */ > noenum additionalMethod() { ... }, > noenum *[Symbol.iterator]() { ... }, > }); > ``` > > Object.assign vs Object.copyOwnProperties may seem awkward, but it's arguably > comparable to the Object.keys/Object.getOwnPropertyNames dichotomy - one for > the common case, one for the thorough case. (I'm aware that > Object.getOwnPropertyNames is deprecated in favour of Reflect.ownKeys, > though.) > > In cases where all the methods are new, this could be "simplified" to: > > ``` > Object.copyOwnProperties(Foo.prototype, class { > baz() { ... } > *[Symbol.iterator]() { ... } > }.prototype); > ``` > > Of course, while writing all this I just thought of yet another problem: > there's no way to copy accessors using this hypothetical > Object.copyOwnProperties. > > Maybe there should also be a specially tuned method on Function: > > ``` > Function.assign(Foo, class { > qux() {...} > *[Symbol.iterator] {...} > get flib() {...} > static flab() {...} > }); > ``` > > And let copyOwnProperties be used for assigning existing methods. > > Classes are kind of an awkward data structure, I must say. :| > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
