Hi Hern��n,

Le 07/12/2015 18:16, Hern��n Morales Durand a ��crit :

Hi Sven

2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu
<mailto:sven@stfx.eu>>:

�� �� There is still #do:displayingProgress:

�� �� There is Job.

�� �� In general, the collection API should not be concerned with GUI
�� �� matters, does it ?


Believe me when you're executing a large workflow processing 50Gb files
with 5 other people expecting feedback from the screen, the least of
your concerns is the purity of collection API. I don't know what other
coders do, kick your co-workers off the room? Sit to see a blank Pharo
screen?
To me the key is to have feedback from the system without having to
change your 20 iterators in a group of client classes where you NEED to
see progress.

Anyway I agree with you Collection should not have GUI dependencies,
that's the reason I took a different approach and that's why I asked
with an expression like:

SmalltalkImage setDisplayProgressTo: MyClass.

with such kind of expression you never touch the Collection API. You
just walk MyClass for every enumeration messsage send (of your interest)
and perform a transformation. Note the same "technique" could be applied
for logging and/or profiling.

Yes. The Jejak tracer uses a similar technique. I'd guess others do as well.

�� �� We can't have equivalents of all collection methods for displaying
�� �� progress, nor can it be a (semi-) global setting.


Sure, that would be the anti-object technology :)

So I implemented a prototype which injects JobProgress code in methods
using RBParseSearchTree. On uninstall I plan to recover the previous
version of marked methods. No need to touch the Collection API at all,
nor a setting. I am sure the same could be done with MethodWrappers but
RB can manipulate AST nodes.

However if there is a better idea I would love to hear about it.

Could you put your RBParseTreeRewriter scripts somewhere? I'm interested.