Kevin Smith <mailto:[email protected]>
September 27, 2013 9:44 PM
All the noise we made about Object.extend was unclear? From jQuery:
https://github.com/jquery/jquery/blob/master/src/core.js#L157
Many similar functions, going back to Prototype's Object.extend:
Object.extend = function(destination, source) {
for (var property in source)
destination[property] = source[property];
return destination;
};
Thanks. I believe this supports my position.
Make your case first!
Regardless of how @iterator is defined, consider this:
extendObject(target, someObjectWithIterator);
If `someObjectWithIterator` has an @iterator method (be it string or
symbol keyed), I would expect that after this statement runs, `target`
would also have that @iterator method.
Any Prototype or jQuery user would be surprised to have meta-level
additions show up, possibly breaking extant code. We can't reason _a
priori_ about such extensions and their effects on backward
compatibility and say "always good" or "always bad".
Furthermore, Object.extend's second argument is almost universally an
object literal. No issue in that common case, but exceptional cases
express the second argument differently. If it happens to be an array,
while the first is not an array, who knows what's "right"? What the
author intended was what happend in the older engines that don't have
the extension.
To write it a different way:
extendObject(target, {
"@iterator"() {}
});
Or:
extendObject(target, {
[Symbol.iterator]() {}
});
Either way I would be surprised if the "iterator" function was **not**
copied.
The final challenge for existing libraries that use for-in loop: if we
add symbols to JS, they will violate the always-stringified enumerable
property key definition of for-in.
I think this example argues for enumerability, at least in some cases.
AHA! :-P
We can agree on "at least in some cases". The problem is the language
extension cannot distinguish the cases and "do the right thing" always.
Your proposal keeps identifiers string-equated, so any enumerable
property with such an "@..." name will be visited by for-in, of course.
With symbols, to avoid surprising existing for-in-based code, we must go
the other way and provide Object.getOwnPropertySymbols as in ES6's
latest draft.
Or equivalently, not all meta-level hooks appear to want
non-enumerability.
Even for @iterator, it depends. The array Object.extend source with
non-array target is one possibility.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
