FWIW when I mixin objects (that are considered traits) into classes [1],
methods and accessors are assigned as other classes methods/accessors would
(non enumerable)
It feels right and work as expected, so your example would simply be
```js
class Foo {
with: [{
bar, /* Existing method */
additionalMethod() { ... }, /* New method */
}],
...
}
```
all at definition time which is IMO easier to read and follow too.
All other utilities to eventually extend in a different ways could be
always used, of course, but I think there should be some
imported-into-class behavior provided by mixins or with or traits or
however that will be called when it'll be the right time.
Just my 2 cents, Best Regards
[1] https://github.com/WebReflection/es-class/blob/master/FEATURES.md#with
( see Aplication class )
On Fri, Feb 20, 2015 at 9:51 AM, 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
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
