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

Reply via email to