On 25.10.16 18:46, Semyon Sadetsky wrote:
I wonder why he should decide that the old code can be "simply
replaced" by the new one? I suppose that at least he should read the
specification of the new extended API. There is no notion that this
api is replaced by the new one, there is a recommendation that the new
one should be used instead.
After reading such recommendation it's hard to conclude that one "should
read the specification of the new extended API". Even "@see" tag
pointing to the extended API is not provided (I'm not even mentioning
the warning that the extended API may be nonequivalent replacement is
absent). I read this recommendation as it is: replace one constant with
another, no side effects expected.

Good to know that you don't read the specification of the methods before using. So what is your proposal? Should I add a notion that these extendent constants contains different int values, and if the user depends from them in some way then he should not replace the old one to the new one? Or what @see reference should be added from some fields to another?


We already have a notions that these "extended modifier constant"
should be used in the constructor of InputEvent and moreover in spec
of getModifiersEx() we have an additional examples how to use this
constants. This is why we will have a reference from old constans to
the new, and from getModifiers() to the getModifiersEx();



--
Best regards, Sergey.

Reply via email to