array like objects

Mike Samuel mikesamuel at gmail.com
Sun Dec 13 10:31:20 PST 2009


2009/12/12 Garrett Smith <dhtmlkitchen at gmail.com>:
> On Sat, Dec 12, 2009 at 4:04 PM, Mark S. Miller <erights at google.com> wrote:
>> On Sat, Dec 12, 2009 at 3:38 PM, Garrett Smith <dhtmlkitchen at gmail.com>
>> wrote:
>>>
>>> On Sat, Dec 12, 2009 at 2:59 PM, Mark S. Miller <erights at google.com>
>>> wrote:
>>> > Are we really this stuck? Can anyone think of a reliable, portable, and
>>> > fast
>>> > ES3R test that tests whether a property is enumerable, whether it is
>>> > inherited or not?
>>> >
>>>
>>> Not stuck. Why do you care if |length| is enumerable?
>>>
>>> If a standard |for| loop is used, it doesn't matter.  Why anyone would
>>> want to use |for in| for something that is arrayLike?
>>
>>
>> |for in| is not my concern. I wish a predicate that has little chance of
>> false positives against legacy ES3 user constructed objects.
>
> Why the need to distinguish between a user-defined object that is
> intended for iteration vs one that is not? The program should already
> know. If the needs of a program are to iterate over an object's

If programmers only wrote programs that would be true.  But they also
write libraries for consumption by other programmers, and many come
from languages that encourage duck-typing : if it enumerates keys like
a duck ...


> indexed properties, possibly filtering, mapping, etc, then allowing
> the algorithm to throw errors at Step 0 seems like a recipe for IE (a
> disaster).

Please clarify a "recipe for IE"

> [snip]
>
> I am still a bit fuzzy on what your "arrayLike" means or is intended
> for. Allen pointed out on previous thread[1] that Array generic
> methods provide an implicit contract. What that contract is depends on
> the method and arguments.

It is meant to help library writers write generic code themselves that
choose an appropriate iteration mechanism.


> Array.prototype.slice, when supplied with one argument, has the
> following implicit contract for the thisArg:
>  1) [[Get]]
>  2) [[HasProperty]] checks
>
> An object that can do those two, but also has a - length - property
> has enough functionality so that a call to - ([]).slice.call( anObject
> ) - would be expected to return an array that has anObject's numeric
> properties, except for the specification allowing "anything goes" with
> Host object and we see "JScript Object Expected" errors in IE.
>
> Allen has not yet commented on that.
>
> Stronger wording for Host object in ES specification would provide
> stronger incentive for implementations (IE) to use host objects that
> have consistent functionality. IOW, if the Array.prototype.slice says:
>
> | 2. Call the [[Get]] method of this object with argument "length".
>
> [[Get]] works via property accessor operators, as in:-
>
> k = anObject.length >>> 0;
>
> - then that step of the algorithm should succeed.
>
> Once an Array is obtained, then the program can use the other
> Array.prototype methods on that object.  Alternatively, if the
> object's functionality is known by the programmer and the
> functionality fulfills an implicit contract for a generic method, then
> the program should be able to use that method, host object or not. At
> least, I would like it to be that way.
>
> | var anObject = document.body.childNodes;
> | function fn( obj ) { return /foo/.test(obj.className); };
> | Array.prototype.filter.call( anObject, fn );
>
> Or (Spidermonkey only):
>
> | function fn( obj ) { return /foo/.test(obj.className); }
> | Array.filter( document.body.childNodes, fn );
>
> ES5 allows the algorithm to terminate at step 0, so that approach is
> not viable.
>
> A for loop could be used, however the downside to that now the program
> uses a user-defined makeArray function.
>
> makeArray( anObject ).
>  filter( function(obj) { return /foo/.test(obj.className); });
>
> Which requires double iteration over the collection, plus the overhead
> of an extra call, plus the extra makeArray function, downloaded and
> interpreted and loaded in memory. This sort of thing is often mired in
> the bowels of today's popular libraries.
>
> In contrast, the generic algorithm in question could be specified to
> execute each step, regardless of whether or not the argument is a host
> object.
>
> Whether or not the execution of that step results in error depends on
> the particular object's implementation. This way, if an object
> supports [[Get]], an Array method that calls [[Get]] could be expected
> to succeed. However if the object has a readonly - length - property,
> or - length - is a getter with no setter, then it would be expected to
> throw an error.
>
> Is this idea reasonable or feasable, from a spec standpoint or
> implementation standpoint?
>
> This is a very very old issue these errors are still coming in IE8,
> but do not appear in other major browsers (AFAIK). Is stronger wording
> for host objects a good idea?
>
> Garrett
>
> [1]https://mail.mozilla.org/pipermail/es-discuss/2009-May/009310.html
> [2]https://mail.mozilla.org/pipermail/es-discuss/2009-December/010241.html
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list