Illustrating handlers sharing problem and proposing a solution

[StevenCostiou]

The solution includes a simple container class in handlers, intended to share a common object named "model". That model implements common behavior and shares data to be used upon a proxified method execution.

Naming and implementation are maybe wrong, I'm trying to illustrate my usecase simply and quickly.

[guillep]

Yes I think you're right. I also think that by default handlers should not know the proxy. Moreover, the instance variable is not used in any but one subclass. Thus it's probably better that we remove that setter + inst var.

I propose that if some handler would like to have a reference to the proxy then:

• it should be done at the level of that handler
• it should validate that the proxy is not set twice and fail with a nice exception :)

That could be part of a handler subclass available to users. I don't know what name could be put in there. MpSingleProxyHandler?

[guillep]

It's even worse. The only usage, MpProfilingHandler, is buggy. It's usage of the proxy instance variable is wrong, it needs the proxified method instead.

[guillep]

I think that not having a reference from the proxy to the handler (as in https://github.com/pharo-contributions/MethodProxies/pull/3) solves already this issue.

Let's see how it goes and reopen this one if needed.