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
As of v3.8, in order to define a field, one should use the FieldDefinition API. This API provides 5 methods to define field properties (named, ofType, inClass, isAnnotatedWith and hasModifiers).
As a library user, this limited set of properties makes it impossible to use a custom condition on a field, for example field.isSynthetic().
As a library developer, I will need to update the API each time a user asks to add a custom field property.
A better approach is to use a Predicate<Field> as a replacement for FieldDefinition. Thanks to java.util.function.Predicate#and and java.util.function.Predicate#or, multiple predicates can be combined to define a field just like FieldDefinition, adding the flexibility to define custom conditions without having to change the API each time. Here is an example:
Random Beans would provide common predicates and let the user define additional predicates as needed. A first work on this feature can be reviewed in branch predicates.
BTW, this idea came from a situation where I wanted to exclude all types defined in a given package. I though about adding a TypeDefinition API allowing one to write something like:
But then I found myself exposing all properties of a Class. I quickly realized that this was not the best approach.. Hence the idea of using predicates: No need to expose properties + ability to provide custom conditions.
The text was updated successfully, but these errors were encountered:
As of v3.8, in order to define a field, one should use the
FieldDefinition
API. This API provides 5 methods to define field properties (named
,ofType
,inClass
,isAnnotatedWith
andhasModifiers
).As a library user, this limited set of properties makes it impossible to use a custom condition on a field, for example
field.isSynthetic()
.As a library developer, I will need to update the API each time a user asks to add a custom field property.
A better approach is to use a
Predicate<Field>
as a replacement forFieldDefinition
. Thanks tojava.util.function.Predicate#and
andjava.util.function.Predicate#or
, multiple predicates can be combined to define a field just likeFieldDefinition
, adding the flexibility to define custom conditions without having to change the API each time. Here is an example:Random Beans would provide common predicates and let the user define additional predicates as needed. A first work on this feature can be reviewed in branch
predicates
.@PascalSchumacher WDYT?
BTW, this idea came from a situation where I wanted to exclude all types defined in a given package. I though about adding a TypeDefinition API allowing one to write something like:
But then I found myself exposing all properties of a
Class
. I quickly realized that this was not the best approach.. Hence the idea of using predicates: No need to expose properties + ability to provide custom conditions.The text was updated successfully, but these errors were encountered: