#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 Ichthyostega)

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 Ichthyostega, at 2009-07-12T23:08:42Z

Status: newaccepted

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...

comment:2 by Ichthyostega, at 2009-07-15T05:30:16Z

Priority: normallesser

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 Ichthyostega, at 2009-07-16T16:55:27Z

blockedby: 190

comment:4 by Ichthyostega, at 2009-10-14T01:04:18Z

blockedby: 190
blocking: 190, 283, 319

comment:7 by Ichthyostega, 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 Ichthyostega, at 2009-10-31T23:13:38Z

blocking: 190, 283, 319190, 283, 319, 343, 347, 349, 353, 375, 392, 393

comment:9 by Ichthyostega, at 2009-11-01T00:31:29Z

blocking: 190, 283, 319, 343, 347, 349, 353, 375, 392, 393190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490
Resolution: done
Status: acceptedclosed

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

Last edited at 2022-10-22T00:02:17Z by Ichthyostega (previous) (diff)

comment:20 by Ichthyostega, at 2022-10-21T23:39:21Z

Description: modified (diff)

comment:21 by Undercover Agent, 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 Ichthyostega, at 2026-04-09T19:40:39Z

Description: modified (diff)
Parent Tickets: 190, 283, 319, 343, 347, 349, 353, 375, 392, 393, 482, 490190, 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.

Note: See TracTickets for help on using tickets.