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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
