Here is what I understand. Option 1: an aspect oriented solution where all usages of iterations get rewritten inside a scope to use progress - People showed examples using the RBTreeRewriter - I think that reflectivity should be also considered Option 2: stack introspection - this would not initially create a performance overhead if progress is not used - but there is the side effect of reifying the stack (that should be measured) - anyways, using the notification also reifies the stack so... Orthogonal, I think that an alternative solution to rewrite callers is to use some kind of decorators For example, a wrapper on the collection can handle the progress and be polymorphic to a collection. This simplifies the collection API, and extracts the progress concern into a composable object. Users do not care if a collection is a normal collection or a progress enabled collection. Moreover, the progress object can have a direct reference to a Job, avoiding notifications, and then, maybe having a less impact in performance (due to stack reification). OrderedCollection new do: [ ... ] => normal iteration OrderedCollection new showingProgress do: [ ... ] Then, to deploy such a collection, a code rewriter will just replace every "OrderedCollection new" by "OrderedCollection new showingProgressâ. This goes in the direction of the iterators that were discussed in the other thread. Guille
On 8 dic 2015, at 10:59 a.m., stepharo <stepharo@free.fr> wrote:
Could we have a synthesis of the discussion?
It would be good to have a list of working solutions with pointers.
Stef