2015-12-08 13:53 GMT+01:00 Guillermo Polito <guillermopol...@gmail.com>:
> 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 > Yes. Solutions would also include an adequate kind of watchpoint/metalink (but the RB stuff may still be necessary to know where to put that watch point). > > 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. > Hum. This solution looks a bit more elegant that 1-, but it is finally as complex (need for a wrapper, need for a rewriting pass anyway, maybe simpler than 1)... However, it may be useful if one want to have a progress on only certain classes users of collections. But, then, 2- is even better since it may be able to customize per instance behavior, not only per caller code. Thierry > 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 > > > > >