array like objects
dhtmlkitchen at gmail.com
Sun Dec 13 22:38:02 PST 2009
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?
>> 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.
>> 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?
More information about the es-discuss