Talk:Iterator

message: Concerning the removed text in the Python section by User:Fredrik on 14 Dec 2004:
  "It should be noted that non-sequence collection types, such as dict
   (an associative mapping), do not support iteration directly.  To iterate over
   these collection the user first must convert them to sequence types."
That limitation in the language was only removed as of Python version 2.2.  In all versions of Python prior to that it was/is still true that you can not directly iterate over dictionaries. - Dmeranda 01:18, 17 Dec 2004 (UTC)
thread_title: Untitled

message: The mentioned Python (unknown to me) seems to support "generators".
Apart from this the way iterators were introduced by CLU has been forgotten.
There these are free-standing procedures which have (invisible and implicitly) the loop body as a parameter.
This kind of iterators is supported directly by the above mentioned programming languages.
We have developed the functional equivalent of a CLU iterator in Delphi (16 and 32 bit) using knowledge of the compiler output, and we are using this successfully for years.
With some auxiliary routines (e.g. iterating, see below) the call of an iterator is essentially as follows:
iterator(parameters);  while iterating do  body;
The usual applications are:
Stepping through containers (tree, list, registry, ...; possibly with premature loop end),
and the "perverted" case where only one callback occurs, e.g. allocate and deallocate resources, wait and signal of semaphores, synchronize (run in main thread).
There is no real alternative to such iterators since with means of the high languages (e.g. Delphi, C++, Java) the iterator can not transfer the local scope and can only call a method or a global procedure. This leads to unattractive effort to feed an auxiliary object (this could be the current object as well) with parameters and local variables, call the iterator and finally transfer back all these variables. An iterator supported by the language does not meet such problems!
The Japanese Wikipedia page for this subject seems to contain at least a reference to Ruby...
-- Jasper1711 15:49, 27 July 2005 (UTC)
replies: text: There should be something about Alphard in this article as well. 131.155.99.235 10:58, 26 January 2006 (UTC)
thread_title:  Iterators as in CLU or Ruby 

message: Is someone likely to mention JavaScript iterators? In JavaScript, iteration can easily break if someone pollutes an object in the prototype chain and the code doing the iteration assumes that all iterated elements come from the object and not its prototype chain.
:I don't think JavaScript's iteration qualifies.  As far as i understand it, the for ... in construct can only iterate over the keys of an object/array;  you can't even use it to iterate over the contents of JavaScript's builtin arrays, let alone user-defined containers and sequences.  --Piet Delport 09:59, 24 March 2006 (UTC)
replies: text: What about the for ... of idiom in modern JavaScript? Pastafaryanist (talk) 21:02, 29 March 2022 (UTC)
thread_title:  Iterators in JavaScript 

message: Hi. Tried to look up Enumerator and got a redirection to Iterator. They are definitely not the same as far as I understand. While an Iterator allows me to move over a set of Objects. An enumerator defines a named collection of objects or variables. Or do I get that wrong ?
: Are you thinking of a particular programming language, or in general?  While some languages might assign different meanings to "iterator" and "enumerator", i doubt there's any generalizable difference that Wikipedia can reflect.  --Piet Delport 12:35, 4 May 2006 (UTC)
replies: text:  An enumeration is a type construct (such as an enum in Java or C). Enumerator is synonymous to iterator. Wouter Lievens 14:19, 4 May 2006 (UTC)

text: You're right mixed it up with enumeration...
An enumerator is really a specialized kind of iterator rather than being synomymous with it, and is so-named because of the mathematical concept enumeration, the mapping of the natural number sequence onto a set.  The distinction is that an enumerator usually consecutively numbers the items as the iteration proceeds, whereas an iterator only must produce a sequence, numbered or not.  Consider Python's enumerate(), which indexes a sequence.  And enumerated type is a different programming concept altogether. Dmeranda 15:20, 5 May 2006 (UTC)

text: Good point.  Sadly, though, Python is the only programming language (that i'm familiar with) that uses the term in this more correct sense, instead of as another word for "iterator/iteration".  --Piet Delport 02:39, 7 May 2006 (UTC)
thread_title:  Why do I get a redirecton from enumerator ? 

message: I've been clearing up links to the element page, and for this one I have redirected to element (mathematics).  If this is wrong, please correct.  If the link was aiming at "element" to mean "fundamental part" then there is no such link in WP, please delete the link.
LeeG 12:13, 12 June 2006 (UTC)
replies: text: The term is used here more or less as a general, open-ended synonym for "item" or "member".  While element (mathematics) is not far from the intended meaning, in many cases, none of the set theoretic concepts and connotations described there need apply here, so i'll unlink it.  Thanks for the heads-up.  --Piet Delport 21:52, 13 June 2006 (UTC)
thread_title: Elements disambiguation

message: I definitely agree with merging Iterators into this article.  However it doesn't really appear to offer any additional information not already covered here—with the possible exception of mentioning that stack and queue don't usually require iterators; something I'm not sure needs mentioned anyway.  So I'm really more for just turning Iterators into a redirect to here. --Dmeranda 18:07, 29 July 2006 (UTC)
replies: text: Agreed. Chip Zero 18:45, 24 October 2006 (UTC)
replies: text: Thirded. This article (Iterator) to me is a clearer explanation as well. hateless 20:03, 17 November 2006 (UTC)
thread_title:  Concerning merging [[Iterators]] to this article 

message: The C++ section here mentions Boost lambda functions for inline iterator processing code, but makes no mention of the now native C++0x lambda functions.  I know it's not formally finalised yet, but might it be worth mentioning these anyway as they are very unlikely to not be included, and are already supported be a lot of compilers.Y Less (talk) 12:58, 13 May 2010 (UTC)
thread_title:  C++0x 

message: At the moment there are two subsections dealing with these distinctions: External iterators and the iterator pattern and Implicit iterators , but no "internal iterators" and "explicit iterators" subsections. This results in a lack of distinction between the four. In addition, neither is mentioned in the classifying iterators subsection. If we can have an expert on the subject review and clarify that would be nice. François Robere (talk) 08:20, 9 May 2013 (UTC)
replies: text: Pastafaryanist (talk) 22:03, 29 March 2022 (UTC)

text: I just want to add that explicit and implicit iterators aren't types of iterators, they are just different ways of using them. Internal and external iterators also aren't types of iterators, they just refer to the controller of the iteration (Where, for an internal iterator, the iteration would be controlled by the function specified). So that's why they aren't mentioned in the "classifying iterators" subsection. Also, there are a lot of explicit/implicit usage of iterators "In different programming languages" section. Pastafaryanist (talk) 22:03, 29 March 2022 (UTC)
thread_title:  Explicit vs. Implicit, External vs. Internal 

message: I suggest we write that iterators is an extension to the idea of code reuse. AXONOV (talk) ⚑ 10:16, 26 January 2022 (UTC)
thread_title:  Code reuse