array like objects

Garrett Smith dhtmlkitchen at
Mon Dec 14 23:27:56 PST 2009

On Mon, Dec 14, 2009 at 11:29 AM, Mike Samuel <mikesamuel at> wrote:
> 2009/12/14 Garrett Smith <dhtmlkitchen at>:
>> On Mon, Dec 14, 2009 at 9:34 AM, Mike Samuel <mikesamuel at> wrote:
>>> 2009/12/13 Garrett Smith <dhtmlkitchen at>:
>>>> 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?
>>> Noone is talking about code that has absolutely no idea what its inputs are.
>>> Please see my mail in this thread from 10:10 PST of 8 Dec for examples
>>> of code that knows that an input is either an array-like collection or
>>> a map-style collection but that use different definitions of the
>>> former.


>> That the method accepts *anything*' and returns anything. If - it - is
> Ok, so this goes back to your earlier strawman where you make the
> unsupported assertion that code that accepts *anything* is bad.

Did I write that a method that accepts anything is bad? I wrote:

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

However if you want to argue that a function that is expected to
accept *anything* is going to be without problems, the examples you
provided don't go very far for support that.

There is a reason I keep mentioning issue with IE's Host objects.

The type of problem that would be solved by code that would be using
an isArrayLike method might also be solved by a way to create *real*
array from an object (host or native).  In order to compare that to
isArrayLike, there should be a problem where isArrayLike is a good
solution. The code examples posted were believed to be demonstration
of a need for isArrayLike, without having shown usage pattern.  The
posted code examples do not look like a good solution for *anything*.
I would strongly discourage any web standard from taking influence
from such pieces of code.

By giving too much freedom with Host objects ECMAScript may be partly
responsible for the allowance of this failure.

> about the identity function, the cast operators defined in the
> standard (ToString, ToPrimitive, ToNumber, ToObject), operators like
> +, and some of your favorite array generics (Array.prototype.indexOf)?
>  The more fundamental the operator, the fewer assumptions it can make
> about its inputs.

I think I understood what you intended by "cast operators", though
nonstandard terminology can be the source of confusion. I have no idea
what you are thinking the Identity function is.

>> falsy, such as (false, null, undefined, 0, ""), then the inupt itself
>> is returned.
> That the author did not know this is an unsupported assertion and that
> this somehow makes the code bad is a non sequitur, but I'm not going
> to get sucked into a code purity pissing contest with you.

The code you posted has the comment:-

|  If it walks like a duck and quacks like a duck, return `true`

- so the author intends to return boolean, but instead returns 0,
undefined, null, "". I would not be surprised if the author actually
does not know what his own code does. We also have the typeof it ==
"array" test, and so the author doesn't know the possible results for
typeof, either.

It is not a pissing contest; the code is far from being sufficient
justification for any proposal. Most of the code in most of these
libraries (Google closure, Dojo) is of poor quality.

> Please explain what this has to do with any of the following questions:
> (1) Should TC39 render an opinion on what is array like?
> (2) If (1), what is array like?

What are you doing with it?

> (3) If (!1), should future EcmaScript drafts define iteration order
> for arrays as index order and possibly recommend to array like host
> objects that the define iteration order similarly.

Why would you want that? So you can use for-in on a host object?


More information about the es-discuss mailing list