Day 2 meeting notes

[Brendan Eich]

On Jul 30, 2010, at 9:51 PM, felix wrote:

> On 7/30/10 21:33, Dean Landolt wrote:
>> [overcited text trimmed -- please trim too when you reply in future. /be]

>> But they're different objects entirely. If a's a "values" iterator it's
>> not iterating over it's /own/ value stream -- it's iterating over some
>> other object's value stream. Thus, f.hasOwnProperty('bacon') shouldn't
>> work (unless you've bacon'd your iterator, of course, or done some magic
>> with proxy objects). So if f is iterating over an object's value stream
>> then you have a reference to the underlying object if you want to do
>> anything like hasOwnProperty.
> 
> but that breaks functions like
> 
> function shallowCopy(o) {
>  var p = {};
>  for (var k in o) {
>    if (o.hasOwnProperty(k)) {
>      p[k] = o[k];
>    }
>  }
>  return p;
> }

We can make this work even if o is a proxy, by having its handler contain fundamental traps that delegate to Object.prototype. Thus it will appear to be an empty object.

But (see my last reply, sorry for its length) we could also use a proxy whose handler contains only an iterate trap, and let o.hasOwnProperty(k) throw an error for want of any such method. It's not obvious shallowCopy should succeed on a proxy.


> now I have to add a test to that function for the unexpected case that o is an infinite iterator and the for..in loop goes forever instead of enumerating some finite property list.

Only if the o.hasOwnProperty(k) attempt does not throw.


> that's just one example.  I expect that if iteration uses the existing for..in syntax, there will be many similar bits of code that will need to be modified to treat iterators as a special case.

Many developers (see Prototype's Object.extend) leave out the o.hasOwnProperty(k) test. Such code will iloop on an infinite iterator, and browsers police iloops with slow script watchdogs.

If we add new syntax, ignoring the reasons I gave against doing so, this code can continue to do what it has done -- but when given a proxy for o, it may still consume too much time or memory due to the proxy's eager enumerate hook. And of course a proxy could misbehave if its derived hasOwn trap is mis-implemented, or the fundamental getOwnPropertyDescriptor trap is buggy.

The proxy could also do something unusual from its derived get or fundamental getPropertyDescriptor trap, invoked by reading o[k] in the |p[k] = o[k];| statement.

Even now, host objects in certain DOMs will frustrate shallowCopy.

The upshot is that you can't migrate code into the Harmony script type naively. First, because Harmony is built on ES5 strict, which is not runtime-compatible (if no early errors stop you) with older editions. Second, because of new syntax and semantics, including proxies.

At this point I argue meta-programmable for-in via the iterate trap extension to proxies is a distant third.

/be