RFR: 8209437: Mechanism for decoupling consumers and providers of behaviours

[Andrew Dinn]

On 15/08/18 11:36, Erik Österlund wrote:
> Thank you for the entertaining reply. I do see your point, and agree.

Well, as I said at the end, ditto (and I think I also agree :-)

> Curious to hear if you agree that my use case sounds painful enough to
> motivate a mechanism like this, or not.
Yes, I think so. This is indeed the case I was thinking of when I said
that I see /your/ point. One or two CPUs back, I spent some while
working through the GC code trying to understand how the various
closures (and their subtypes) get passed around. As a novice reader of
that code I found it was very difficult to track that flow.

By contrast, your proposal will mean that side-effects may get magically
inserted by some caller up the stack. However, if that reduces the
complexity of the current dataflows to a relatively small number of
magic points where behaviour does actually get thus (side-)affected then
I agree that this will serve to minimise the complexity to be grappled
with. So, it's definitely a two way street and in this case it seems
likely to be less congested in your direction.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander