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