| commit | 92569ab5251944b322c254bd4286c8b61b2fbc47 | |
| author | Shaunak Kishore <kshaunak@fb.com> | |
| Tue, 12 Nov 2019 23:30:38 +0000 (12 15:30 -0800) | ||
| committer | Facebook Github Bot <facebook-github-bot@users.noreply.github.com> | |
| Tue, 12 Nov 2019 23:32:37 +0000 (12 15:32 -0800) | ||
| tree | fc6fe342f5311ab519fc28e76ecbe1d4f4f14c16 | treesnapshot (tar.gz zip) |
| parent | 461437bf19c49832243dea9836dabf61230a039b | commitdiff |
One more case for iter docs
Summary: I missed the collections case when updating these docs. Now that we have this case, it's easier to describe the "next" behavior in terms of the type of the iterator instead of the type of the base. There are two cases - collections -> array iterator and IteratorAggregate -> object iterator - where we coalesce "next" behavior by creating the same kind of iterator for different kinds of bases, so naming the types of iterator is a clean way to reduce this casework.
Reviewed By: mofarrell
Differential Revision: D18457443
fbshipit-source-id: ceeb8187718289f4c98fcc7ae137e648cd52a6eb
Summary: I missed the collections case when updating these docs. Now that we have this case, it's easier to describe the "next" behavior in terms of the type of the iterator instead of the type of the base. There are two cases - collections -> array iterator and IteratorAggregate -> object iterator - where we coalesce "next" behavior by creating the same kind of iterator for different kinds of bases, so naming the types of iterator is a clean way to reduce this casework.
Reviewed By: mofarrell
Differential Revision: D18457443
fbshipit-source-id: ceeb8187718289f4c98fcc7ae137e648cd52a6eb
| hphp/doc/bytecode.specification | diffblobblamehistory |