#182 closed todo (done)
Concept "lumiera forward iterator"
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | lesser | Milestone: | 0integration |
| Component: | lumiera | Keywords: | |
| Sub Tickets: | Parent Tickets: | #190, #283, #319, #343, #347, #349, #353, #375, #392, #393, #482, #490, #1125, #1420 |
Description (last modified by )
Over time, various ad-hoc definitions for iteration were utilised in the code base, especially in Steam-Layer. While typicaly somehow modeled after the iterators in the C++ STL, these can not be combined and each one has its specific twists. A common concept should thus be factored out from the actual usages and applied uniformly, going forward. An iterator should be easy to understand, and usable in for-each loops. Document the new specification by Unit test and write a DesignProcess entry.
Explanation: The STL defines various, intricately layered iterator concepts. Ichthyo considers most of these capabilities to be excessive and geared more towards the implementation of algorithms than serving as a means of abstraction. In contrast, many modern programming languages rely on a radically simple iterator concept that allows one to pull a sequence of values – and nothing more. Providing only such an iterator often leads to clearer APIs.
Thus the idea is to formulate a concept in that is roughly in compliance with STL's input / forward iterator -- but augmented by an stop-iteration test. Obviously, there should be some easy-to-use support templates to help building compliant iterators. This would give us basic STL integration and look familiar to C++ and Java programmers without compromising the clean APIs.
Change history (10)
comment:1 by , at 2009-07-12T23:08:42Z
| Status: | new → accepted |
|---|
comment:2 by , at 2009-07-15T05:30:16Z
| Priority: | normal → lesser |
|---|
I've now implemented 3 basic templates, which should be enough for now to define the Session interface.
TODO: retrofit the existing iterators, more unit test coverage with real-world use cases, document the iterator concept
comment:3 by , at 2009-07-16T16:55:27Z
| blockedby: | → 190 |
|---|
comment:4 by , at 2009-10-14T01:04:18Z
| blockedby: | 190 |
|---|---|
| blocking: | → 190, 283, 319 |
comment:7 by , at 2009-10-16T01:26:49Z
...so, what remains here to do?
- write a Design-Process entry to document the concept.
- have a look at existing iterators, which could be retrofitted easily
- create tickets for the remaining iterators, to be cleaned up later
The summary of the concept, as it's implemented now, can be found in the doxygen of lib/iter-adapter.hpp
comment:8 by , at 2009-10-31T23:13:38Z
| blocking: | 190, 283, 319 → 190, 283, 319, 343, 347, 349, 353, 375, 392, 393 |
|---|
comment:9 by , at 2009-11-01T00:31:29Z
| blocking: | 190, 283, 319, 343, 347, 349, 353, 375, 392, 393 → 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490 |
|---|---|
| Resolution: | → done |
| Status: | accepted → closed |
Successfully used now within QueryResolver. Cleaned up the back-link in IterAdapter. Wrote a documentation Page to the TiddlyWiki and also used the same text as DesignProcess-Entry
comment:20 by , at 2022-10-21T23:39:21Z
| Description: | modified (diff) |
|---|
comment:21 by , at 2025-12-25T00:00:00Z
| blocking: | 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490 |
|---|---|
| Parent Tickets: | → 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490 |
Migration MasterTickets ⟼ Subtickets-plugin
comment:3 by , at 2026-04-09T19:40:39Z
| Description: | modified (diff) |
|---|---|
| Parent Tickets: | 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490 → 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490, 1125, 1420 |
Has become a core element of Lumiera
Many years later, this Forward Iterator Concept evolved into a cornerstone and defining element in the codebase. It has proven to be flexible, robust and easy to implement — and gave rise to various elaborate functional evaluation patterns. Notably the IterExplorer allows to build processing pipelines, optionally with dynamic tree expansion and depth-first search.

doing some initial steps here, because I need to write yet more iterators...
probably this will stay unfinished for some time to come, because I've more urgent other work...