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