array like objects

Garrett Smith dhtmlkitchen at
Sun Dec 13 22:38:02 PST 2009

On Sun, Dec 13, 2009 at 10:31 AM, Mike Samuel <mikesamuel at> wrote:
> 2009/12/12 Garrett Smith <dhtmlkitchen at>:
>> On Sat, Dec 12, 2009 at 4:04 PM, Mark S. Miller <erights at> wrote:
>>> On Sat, Dec 12, 2009 at 3:38 PM, Garrett Smith <dhtmlkitchen at>
>>> wrote:
>>>> On Sat, Dec 12, 2009 at 2:59 PM, Mark S. Miller <erights at>
>>>> 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 ...

What well-designed piece of code has absolutely no idea what its input is?

>> 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"

IE tends to take allowances for things whenever allowed to do so.
Where the spec says "implementation dependent", IE will do something
either useless or harmful.

| Whether the slice function can be applied successfully to
| a host object is implementation-dependent.

That note allows an implementation to throw an error if the thisArg is
a Host object, without attempting to run the algorithm. That's a
recipe for IE and IE is a disaster.

I am suggesting a change so that an ES algorithm will run as specified.

Other things IE will do is not implement, throw errors, or provide
wacko results for [[HasProperty]], [[Get]], [[ToBoolean]] internal
properties. It is worth noting that prior to ES5, this was allowable.

Fortunately, ES5 rectified that with:

| Every object (including host objects) must implement all
| of the internal properties listed in Table 8.

Which includes properties [[Get]], [[HasProperty]], et al.

That is a change that I strongly endorse. Whether or not IE will
change to comply with that requirement has yet to be seen.

>> [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.
I'm getting fuzzier. What is the method doing? Do you have a real example?


More information about the es-discuss mailing list