array like objects

Mike Samuel mikesamuel at gmail.com
Mon Dec 14 11:29:06 PST 2009


2009/12/14 Garrett Smith <dhtmlkitchen at gmail.com>:
> On Mon, Dec 14, 2009 at 9:34 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> 2009/12/13 Garrett Smith <dhtmlkitchen at gmail.com>:
>>> On Sun, Dec 13, 2009 at 10:31 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
>>>> 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 ...
>>>>
>>>>
>>>
>>> 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.
>>
>
> You mentioned several code examples earlier:
>
> Please see the thread where I mentioned "mired in the bowels of
> today's javascript libraries".
>
> Those examples are vague. They mostly try to address all possible
> cases, but don't do a very good job when the argument is a Host
> object. The fact that these things are considered reliable is an
> indication to the poor understanding of javascript.

> Take a snip from one of your shining examples:

This is just another of your strawmen.  I specifically said that these
were examples of code defining array like-ness in various ways.  I
never said they were examples of great code.

> |       dojo.isArray = function(/*anything*/ it){
> |               //      summary:
> |               //              Return true if it is an Array.
> |               //              Does not work on Arrays created in
> other windows.
> |               return it && (it instanceof Array || typeof it ==
> "array"); // Boolean
> |       }
>
> 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.  What
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.


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

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?
(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.

> OTherwise there is a check to - it instanceof Array -
> which will always be false cross-frame/window. Third, there is typeof
> it == "array", which will always be false. ALthough it is funny to see
> how many mistakes dojo can cram into a single line of code, the fact
> of the matter is that Dojo authors are not competent or knowledgeable
> of ECMAScript.
>
> Keep going?  OK...

> | dojo.isArrayLike = function(/*anything*/ it){
> |        //      summary:
> |        //              similar to dojo.isArray() but more permissive
> |        //      description:
> |        //              Doesn't strongly test for "arrayness".
> |        //              Instead, settles for "isn't a string or
> |        //              number and has a length property".
> |        //              Arguments objects and DOM collections
> |        //              will return true when passed to
> |        //              dojo.isArrayLike(), but will return false
> |        //              when passed to dojo.isArray().
> |        //      returns:
> |        //              If it walks like a duck and quacks like a
> |        //              duck, return `true`
> |        // return it && it !== undefined && // Boolean
> |        // keep out built-in constructors (Number, String, ...)
> |        // which have length properties.
> |                !d.isString(it) && !d.isFunction(it) &&
> |                !(it.tagName && it.tagName.toLowerCase() == 'form') &&
> |                (d.isArray(it) || isFinite(it.length));
> | }
>
> So we have a function which again takes *anything* and passes
> *anything* to d.isString d.isFunction which can be assumed to be
> similar in quality to their isArray function. Next, exclude any object
> that does has a tagName property "form" (case-insensitive). Finally,
> return true if d.isArray || isFinite(it.length). That includes
> textNodes, comment nodes, and probably a ton of other Host objects.
>
> The dojo.isArrayLike method tries to do something with anything, isn't
> very clear about what it does, and creates confusion by being posed as
> something competently written.
>
> Copying such things is obviously a poor idea. Basing APIs on such
> things is part of the "death spiral". and I'm out of time.
>
> Regards,
>
> Garrett
>


More information about the es-discuss mailing list