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. :|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150220/9ca1b9ef/attachment.html>

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. :|