You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often in Java projects, fields of interest are declared either as public, in which case there are rarely getX and setX methods, since the field can be set directly; or as private, with public getX and setX if some view of that field is intended to be viewed publicly.
In the case that the source package is not annotated to let us know what to index on, we should assume indices on fields which match these patterns, and behave accordingly.
For finer-grained control, sometimes get* methods look as if they are accessing fields which don't actually have a corresponding setter. In this case, we should expose annotations to let us know which methods will affect the values returned by those methods.
For now we should only assume that getX and setX correspond to a private field x if that field is named exactly x (or perhaps _x, or some other naming variant), and it is clear we know what is happening.
We should be careful to avoid incorrect assumptions in this case, but we should start moving toward making MercuryDB compatible with libraries we don't maintain, as much as possible.
The text was updated successfully, but these errors were encountered:
Often in Java projects, fields of interest are declared either as public, in which case there are rarely getX and setX methods, since the field can be set directly; or as private, with public getX and setX if some view of that field is intended to be viewed publicly.
In the case that the source package is not annotated to let us know what to index on, we should assume indices on fields which match these patterns, and behave accordingly.
For finer-grained control, sometimes get* methods look as if they are accessing fields which don't actually have a corresponding setter. In this case, we should expose annotations to let us know which methods will affect the values returned by those methods.
For now we should only assume that getX and setX correspond to a private field x if that field is named exactly x (or perhaps _x, or some other naming variant), and it is clear we know what is happening.
We should be careful to avoid incorrect assumptions in this case, but we should start moving toward making MercuryDB compatible with libraries we don't maintain, as much as possible.
The text was updated successfully, but these errors were encountered: