Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRename methods Reflect#on(Class) and Reflect#on(String) to onClass() to avoid ambiguities #78
Comments
lukaseder
added
P: Medium
T: Enhancement
T: Incompatible change
labels
Feb 11, 2019
lukaseder
added this to the Version 0.9.11 milestone
Feb 11, 2019
lukaseder
referenced this issue
Feb 11, 2019
Closed
Reflect on(Class<?> type, Object object) become public? #55
lukaseder
removed
the
T: Incompatible change
label
Feb 11, 2019
This comment has been minimized.
This comment has been minimized.
While the change is quite intrusive (lots of deprecations in calling code), it is not backwards incompatible. We'll remove the deprecated methods in jOOR 1.0. When reflecting on |
added a commit
that referenced
this issue
Feb 11, 2019
lukaseder
added
the
R: Fixed
label
Feb 11, 2019
lukaseder
closed this
Feb 11, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
lukaseder commentedFeb 11, 2019
The current overloading of
Reflect.on()
is unfortunate in a few cases where people want to reflect on instances ofString
orClass
, but accidentally bind to the more specific methods that do something quite different fromReflect#on(Object)
. See e.g. #55Those methods shouldn't overload the base method, but have an entirely different name. The old methods will stay in place and will be deprecated to document this change.