Discuss
  • Object.mixin rather than Object.getOwnPropertyDescriptors

Object.mixin rather than Object.getOwnPropertyDescriptors

# Claude Pache (11 years ago)

There has been request to add Object.getOwnPropertyDescriptors (plural) to the standard. Reviewing use cases presented in thread [1] or in older thread [2], it seems to me that all of them boil down to copy all own properties of one object to another, e.g.,

Object.defineProperties(target, Object.getOwnPropertyDescriptors(source))
Object.create(proto, Object.getOwnPropertyDescriptors(source))
// etc.

However, this is exactly what Object.mixin (deferred from ES6) was designed for:

Object.mixin(target, source)
Object.mixin(Object.create(proto), source)
// etc.

Besides being shorter to write, Object.mixin has the advantages of (1) not creating an intermediate object; (2) taking care of some subtleties, like rebinding super for methods, getters and setters if needed.

Therefore, I think that Object.mixin is a better function to have than Object.getOwnPropertyDescriptors.

—Claude

[1] esdiscuss.org/topic/object-getownpropertydescriptors-o-plural [2] esdiscuss.org/topic/object

# Andrea Giammarchi (11 years ago)

while I think that

Object.create( Object.getPrototypeOf(originalObject), Object.getOwnPropertyDescriptors(originalObject))

looks semantically better than

Object.mixin( Object.create(Object.getPrototypeOf(originalObject)), originalObject)

I also think that Object.mixin could be used for similar cases but I am not sure if:

  1. is able to mixin also not enumerable and Symbols
  2. performs some unrequired magic such rebinding getters and setters that should not happen or actually does not make sense to me

The reason such long method name has been proposed was for symmetry with defineProperties and as meaningful plural version that should not exclude Object.mixin

Long story short, when mixin is needed, use mixin, otherwise when all descriptors are needed, use getOwnPropertyDescriptors?

In few words I don't see how having both could hurt anyone

# Claude Pache (11 years ago)

Le 22 avr. 2014 à 19:58, Andrea Giammarchi <andrea.giammarchi at gmail.com> a écrit :

while I think that Object.create(

Object.getPrototypeOf(originalObject),

Object.getOwnPropertyDescriptors(originalObject) ) looks semantically better than Object.mixin(

Object.create(Object.getPrototypeOf(originalObject)),

originalObject

) I also think that Object.mixin could be used for similar cases but I am not sure if: • is able to mixin also not enumerable and Symbols

When it was still in the ES6 draft, Object.mixin did copy all own properties.

• performs some unrequired magic such rebinding getters and setters that should not happen or actually does not make sense to me

My feeling is that in most cases where that magic is not required, it is also not very important. Or there could be an option for enabling/disabling that functionality, for that would seem better to me than two wildly different ways for getting almost the same result.

The reason such long method name has been proposed was for symmetry with defineProperties and as meaningful plural version that should not exclude Object.mixin

Long story short, when mixin is needed, use mixin, otherwise when all descriptors are needed, use getOwnPropertyDescriptors?

Do you have cases where getting all descriptors is used for something else than setting them immediately to another object? My point is that I don't see the added value of Object.getOwnPropertyDescriptiors once you have a correctly designed Object.mixin-like method.

# Andrea Giammarchi (11 years ago)

IMO every time you use getOwnPropertyDescriptor over a getOwnPropertyNames you are asking for a getOwnPropertyDescriptors implementation, that's the use case.

Twisting your question, do you have any use case for getOwnPropertyNames that won't require later on getOwnPropertyDescriptor ?

# Claude Pache (11 years ago)

Le 22 avr. 2014 à 21:05, Andrea Giammarchi <andrea.giammarchi at gmail.com> a écrit :

IMO every time you use getOwnPropertyDescriptor over a getOwnPropertyNames you are asking for a getOwnPropertyDescriptors implementation, that's the use case.

And in these cases, again, are the descriptors used for something else than applying them immediately to another object? (This is a real question, for personally I barely use getOwnPropertyNames for other purpose than debugging.)

Twisting your question, do you have any use case for getOwnPropertyNames that won't require later on getOwnPropertyDescriptor ?

Maybe, but Object.getOwnPropertyNames and Object.getOwnPropertyDescriptor (in ES5) are fundamental methods that cannot be decomposed into other methods, and on which libraries can build more complex functionalities. (Not sure about the getOwnProperty{Names,Symbol} dichotomy of ES6, but that's another question.) On the other hand Object.getOwnPropertyDescriptors and Object.mixin are complex methods.

# Andrea Giammarchi (11 years ago)

getOwnPropertyDescriptors retrieves at once everything that both getOwnProperty{Names,Symbol} plus getOwnPropertyDescriptor per each name or symbol would .. we have few shortcut/utilities in ES, why you see this so useless? Even Array#forEach can be decomposed in a for loop ... how about using getOwnPropertyDescriptors for debugging too?

All I am saying is that I don't see why this should not land ... there's much more to do for ES7 than this, IMO, like ... finalizing specs for Object.mixin and then eventually talk about dropping this already spec'd one

# Rick Waldron (11 years ago)

On Tue, Apr 22, 2014 at 1:27 PM, Claude Pache <claude.pache at gmail.com>wrote:

Hi,

There has been request to add Object.getOwnPropertyDescriptors (plural) to the standard. Reviewing use cases presented in thread [1] or in older thread [2], it seems to me that all of them boil down to copy all own properties of one object to another, e.g.,

Object.defineProperties(target,

Object.getOwnPropertyDescriptors(source)) Object.create(proto, Object.getOwnPropertyDescriptors(source)) // etc.

However, this is exactly what Object.mixin (deferred from ES6) was designed for:

Object.mixin(target, source)
Object.mixin(Object.create(proto), source)
// etc.

Besides being shorter to write, Object.mixin has the advantages of (1) not creating an intermediate object; (2) taking care of some subtleties, like rebinding super for methods, getters and setters if needed.

Therefore, I think that Object.mixin is a better function to have than Object.getOwnPropertyDescriptors.

The latter is not replacing the former; they are different APIs for different use cases. For example, Object.mixin cannot be used to derive descriptors from an object and filter then properties by descriptor attribute value:

// module.js
function descriptorsByAttributeFilter(o, filter = {}) {
  var descriptors = Object.getOwnPropertyDescriptors(o);
  var filters = Object.keys(filter);

  return Object.keys(descriptors).reduce((accum, key) => {
    var descriptor = descriptors[key];

    if (filters.every(field => descriptor[field] === filter[field])) {
      accum[key] = descriptor;
    }
    return accum;
  }, {});
}

export function writables(o) {
  return descriptorsByAttributeFilter(o, { writable: true });
}

export function nonwritables(o) {
  return descriptorsByAttributeFilter(o, { writable: false });
}


// script.js

import {writables, nonwritables} from "module";

var o = Object.defineProperties({}, {
  thisisnonwritable: {
    value: 1, writable: false
  },
  thisiswritable: {
    value: 2, writable: true
  }
});

console.log( writables(o) );
console.log( nonwritables(o) );
# Marcus Stade (11 years ago)

I have a use case for Object.getOwnPropertyDescriptors – it may or may not be to your liking, but I have one. I'm currently implementing a library to help with employing more pure functional programming techniques in JavaScript environments. This includes such things as (mostly) forcing immutability, devising copy-on-write schemes etc. One thing in particular that I'm devising is a kind of Type object, which is little more than a set of fields to provide structural guarantees and some rudimentary semantic abilities (is-a type stuff.) In constructing these, I'm using an API that looks something like this:

const MyType = deftype("MyType", BaseType,
  { field: 1
  , get something() { return this.x }
  , set something(val) { this.x = val }
  }
)

const myInstance = MyType({ field: 5 })

The third argument to the deftype function is an object – any object – where the fields are inspected and stored as a sort of template for subsequent instance creation. The field descriptors are modified to always be non-configurable, and for fields that aren't a get/set combo they're also always set to be immutable. Additionally, I'm doing some rebinding of functions such that they have an implicit internal scope (hence the this in the accessors above) which makes it a lot easier to reason about internal state. Currently the way this is done is through a combination of getOwnPropertyNames and getOwnPropertyDescriptor.

I'd have to agree with Andrea and say – somewhat rhetorically – why not? It seems like a harmless addition. That said, that it doesn't exist is mostly just an annoyance.