On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff <jason.orendo...@gmail.com > wrote:
> On Wed, Jun 26, 2013 at 7:54 PM, Dean Landolt <d...@deanlandolt.com> > wrote: > > On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff < > jason.orendo...@gmail.com> > > wrote: > >> > What if iterator is present but not a function? Do you walk > >> > the prototype chain anyway? Blow up? Punt and lookup an iterator > >> > directly > >> > based on a mapping with some type testing? [...] > >> > >> Well, no, it should be treated like any other non-iterable object. > > > > Oh? I know I've personally created boolean database columns named > "iterator" > > -- I'm sure I'm not alone. I pity the poor ORM user that tries to pass > their > > objects to a library function which tries to iterate without fallback. Of > > course we know what's going to happen -- confusing bug reports will > pressure > > library authors to hack in fallbacks, or just skip the unstratified > iterator > > call entirely. Do you disagree? How else do you see libraries handling > this > > specific case? > > I think I disagree, but I'm afraid I don't fully appreciate your point yet. > > If you mean a library function that expects either an iterable or a > dictionary, then it would correctly treat your non-iterable data > object as a dictionary. So... I guess I don't see the problem. > Everything seems fine. > > Surely "length" is a more common database column name than "iterator". > So if you're right, surely we already have these problems with > existing library functions that take arraylike objects. Is that the > case? Are there confusing bug reports and hacked-in fallbacks? > Apples and oranges -- people don't use arrays as maps. I've seen countless cases where object keys . Perhaps a better example would be `hasOwnProperty` -- I know there have been bug reports. The MDN page goes out of its way to warn about this [1]: JavaScript does not protect the property name hasOwnProperty; thus, if the possibility exists that an object might have a property with this name, it is necessary to use an *external* hasOwnProperty to get correct results ... That's right -- MDN goes out of its way to recommend `Object.prototype.hasOwnProperty.call`. This is *exactly* what I fear. It's not a huge loss for hasOwnProperty (or toString) -- experienced JS devs just accept the fact that polymorphism can't be counted on for these properties. It would be tragic for this fate to befall `iterator` polymorphism. In part because it's unnecessary, but also because polymorphism is central to iterator's usefulness (which I know you agree about, otherwise you wouldn't be arguing so forcefully against symbol-based keys). [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
