Re: Property enumeration on forms

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:10 UTC