On 01/04/18 04:56, Jonathan M Davis wrote:
Another potential issue is whether any of this does or should relate to


and it's solution for hooking into to moves. I'm not at all sure that what
happens with that needs to be related to this at all, but it might.

- Jonathan M Davis

I was actually going to start a new thread about it.

On the one hand, nothing in the opMove DIP is directly affected by this. On the other, if we're moving away from "copy and then fix" mentality, then opMove should also reflect this.

The problem is that the alternative solution has a much bigger impact on backward compatibility. I'm really tempted to try and push this DIP as is, only renaming "opMove" to "opPostMove". This way, we can push the simpler version as is, and when (and it will take a while) "this(this)" deprecation finally comes, we can implement "opMove" as an in-process user hook.


Reply via email to