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
>