<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff <span dir="ltr"><<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Wed, Jun 26, 2013 at 10:20 AM, Dean Landolt <<a href="mailto:dean@deanlandolt.com">dean@deanlandolt.com</a>> wrote:<br>


> I assume the primary reason to hang the iterator reference directly off an<br>
> object is so that it can be prototypally overloaded -- would you agree?<br>
<br>
</div>Sure. Polymorphism, therefore a method.<br>
<div class="im"><br>
> Given that library code tends toward being as generic as possible, I can<br>
> just picture the schism in approaches for looking up the Right iterator.<br>
<br>
</div>If we make the name just plain "iterator", there's a conventional<br>
right answer for this: `typeof obj.iterator === "function"`.</blockquote><div><br></div><div>Yes -- my point about the schism is what libraries will decided to do when that test fails. 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? What kind of type testing? If this is easy to avoid, why <i>not?</i><br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">See the<br>
tests for .toString and .valueOf methods in [[ToPrimitive]] (now<br>
OrdinaryToPrimitive in ES6[1]), the test for a .toJSON method in [2],<br>
and the test for .then in DOM Promises.[3]<br></blockquote><div> <br><br></div><div>I strongly suspect the language will evolve these into legacy warts, but as far as I know when these were introduced there weren't bodies of code that would obviously blow up (except [3] , but I'll get to that), and if they were, that blood was spilled long ago. I've come across quite a bit of code that treat objects as maps. Yes, I know we real maps now, and that's great, but authors of generic library code can't just cross their fingers and hope downstream users will do the Right Thing. They'll avoid iterators entirely, or if not, they'll certainly have to skip the `iterator` method lookup if they want to avoid weird bug reports. That's a fail.<br>

<br>And yes, [3] will be a completely unnecessary mistake if allowed to stand, and for similar reasons. Assuming the system module could act as a namespace for branding keys it's completely incomprehensible to my why the Promises/A+ folks would be unwilling to add an attempted lookup for this brand as a synonym for `then` to their spec. This is what I'd proposed as Promises/A++, but nobody seemed terribly interested. But the `then` ducktest has no place in the web platform -- it's nothing but a hazard. But that's a rant for another thread.<br>

<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If it's a symbol, it appears `obj[iteratorSymbol] !== undefined` is<br>
what the spec is doing, at least in one place, the test for a<br>
.@@ToPrimitive method in [1].<br>
<br>
  [1]: <a href="https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.1.1" target="_blank">https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.1.1</a><br>
  [2]: <a href="https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.12.3" target="_blank">https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.12.3</a><br>
  [3]: <a href="http://dom.spec.whatwg.org/#promises-model" target="_blank">http://dom.spec.whatwg.org/#promises-model</a><br>
<br>
Note that IsCallable(obj) is the same thing as `typeof obj ===<br>
"function"`. [4], [5]<br>
<br>
  [4]: <a href="https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.2.2" target="_blank">https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.2.2</a><br>
  [5]: <a href="https://people.mozilla.com/~jorendorff/es6-draft.html#sec-11.4.3" target="_blank">https://people.mozilla.com/~jorendorff/es6-draft.html#sec-11.4.3</a><br>
<br>
Of course existing code on the Web uses every possible flavor of<br>
type-test, and always will, whether the iterator method name is a<br>
string, a symbol, or a suffusion of yellow. "Schism" isn't the word.<br>
"Free-for-all" maybe.<br></blockquote><div><br></div><div>I think you may have missed my point about where the schism is. I hope I've made it more clear above and in prior posts but to restate: the schism isn't the ducktest, it's that the ducktest isn't a <i>quite</i> a predicate -- sometimes it can fail in a way where you may want to proceed up the prototype chain (or do something else). This is where I believe there are interop landmines buried.<br>

</div></div><br></div></div>