- From: Brendan Eich <brendan@mozilla.org>
- Date: Fri, 23 Oct 2009 16:34:19 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, public-script-coord@w3.org, Boris Zbarsky <bzbarsky@mit.edu>, HTML WG <public-html@w3.org>
On Oct 23, 2009, at 3:23 PM, Maciej Stachowiak wrote: > What would your recommendation for form element be - that neither > index nor named properties should be enumerable? Only index > properties enumerable? Here is some information about the ancient days, when dragons roamed the earth: The first JS engine, in Netscape 2, had a notion of aliased properties. Instead of 0, 1, and myInput all appearing to be data properties strongly referencing form elements, where 0 and myInput both happened to refer to the same element, instead myInput would "alias" 0. What this meant (if memory serves; I don't have Netscape 2 to test) was that for-in would enumerate just 0 and 1. The for-in loop is a "DWIM" construct, that is its curse. For collections where some of the elements may have names as well as indexes, what one might "Mean" varies from person to person, and use- case to use-case. Some want only indexes up to length, starting from 0 (insertion order is not relevant, if it can differ from index natural-number order). Others might want to introspect and discover the name of every enumerable property. My two cents: I think what WebKit does is simple to explain in the modern world of no "aliases" other than multiple references to the same object from several properties. It fits the user's model for objects in JS. It allows one to add ad-hoc (expando) properties with similar names and values in common and get similar results. I don't think the catch-all objection stands, if once you have enumerated the properties (or asked for one by name) they persist and behave like data properties. /be
Received on Friday, 23 October 2009 23:35:19 UTC