On Sun, Dec 13, 2009 at 10:31 AM, Mike Samuel <[email protected]> wrote: > 2009/12/12 Garrett Smith <[email protected]>: >> On Sat, Dec 12, 2009 at 4:04 PM, Mark S. Miller <[email protected]> wrote: >>> On Sat, Dec 12, 2009 at 3:38 PM, Garrett Smith <[email protected]> >>> wrote: >>>> >>>> On Sat, Dec 12, 2009 at 2:59 PM, Mark S. Miller <[email protected]> >>>> 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. ES5: | 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? Garrett _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
