Comments on Sept Meeting Notes

Brendan Eich brendan at mozilla.com
Sat Sep 28 10:41:46 PDT 2013


> Kevin Smith <mailto:zenparsing at gmail.com>
> 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


More information about the es-discuss mailing list