array like objects
mikesamuel at gmail.com
Mon Dec 14 09:34:45 PST 2009
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>
>>>>> On Sat, Dec 12, 2009 at 2:59 PM, Mark S. Miller <erights at google.com>
>>>>> > 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
>>> indexed properties, possibly filtering, mapping, etc, then allowing
>>> the algorithm to throw errors at Step 0 seems like a recipe for IE (a
>> 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.
What IE should/does do seems orthogonal to what is array like and
whether TC39 should comment on what is array like.
>>> I am still a bit fuzzy on what your "arrayLike" means or is intended
>>> for. Allen pointed out on previous thread 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?
Please see the mail mentioned above for examples of code, and please
see Mark's mail from 11:12 PST 11 Dec for a proposed convention for
More information about the es-discuss