medikoo / es5-ext

ECMAScript extensions (with respect to upcoming ECMAScript features)
ISC License
174 stars 85 forks source link

Consider rename of normalizeOptions into toPlainObject #57

Open medikoo opened 7 years ago

medikoo commented 7 years ago
  1. normalizeOptions when created, it was assumed that probably it doesn't address any other case as normalizing input options. However now there are few cases when it's used not specifically for that.
  2. It's technically about copying and unifing many objects also across their prototype chain, into one plain object.

One controversy is that we have to* functions which in case of input matching the output, return it directly (and not its copy), while here (at least in case of options normalization) we're always after copy. Maybe we should have both toPlainObject and normalizeOptions where latter will just ensure we have the copy. Or maybe we should make all to* functions return a copy.

Additional note: both toPlainObject and normalizeOptions should copy only enumerable properties. On one side it's controversial as on not transformed options object non-emurable properties remain visible and can be read normally as an options, while after transformation it's not the case. So it makes technically both options objects not equivalent. Still non-enumerable properties, if any (unlikely case) in most cases will be meta properties (e.g. containers for listeners of event emitter, or container of weak map polyfill), copying those opens door to some very hard to track bugs.


Extra notes:

  1. Let's make it one argument taking, as in use cases we have it's only one object we need to copy deep the prototype chain. So multi args handling can be solved as:
    Object.assign({}, defaultOptions, toPlainObject(inputOptions));
  2. Support propertyKeys (or only) option, where list of names (including symbols) can be passed and in such case only those properties are copied. Additionally they should be copied even if they're not enumerable