GutoVeronezi commented on pull request #849:
URL: https://github.com/apache/commons-lang/pull/849#issuecomment-1074440685
Hi, @garydgregory,
Thanks for the review, I'll address the changes regarding the feature name
(`setSelectedFieldNames` -> `setIncludeFieldNames`) as well the documentation
of its use.
---
Regarding the intersection between `included` and `excluded`, I see it as a
complement rather than an intersection; The current behavior of this class, as
you said, is to include all fields by default. If we have a class with fields
`a`, `b` and `c` and instantiate and reflect it, both of them will be
reflected. If we set them in the excluded field names, the reflection will
return empty:
```java
import org.apache.commons.lang3.builder.ReflectionToStringBuilder;
import org.apache.commons.lang3.builder.ToStringStyle;
public class Test {
private String a;
private String b;
private String c;
public Test(String a, String b, String c) {
this.a = a;
this.b = b;
this.c = c;
}
public static void main(String[] args) {
Test test = new Test("this is field 'a'", "this is field 'b'", "this
is field 'c'");
ReflectionToStringBuilder reflection = new
ReflectionToStringBuilder(test, ToStringStyle.JSON_STYLE);
System.out.println(String.format("Before excluding: %s",
reflection.build()));
reflection = new ReflectionToStringBuilder(test,
ToStringStyle.JSON_STYLE); // Recreating the object because once builded it
caches the result.
reflection.setExcludeFieldNames("a", "b", "c");
System.out.println(String.format("After excluding: %s",
reflection.build()));
}
```
Result:
```
Before excluding: {"a":"this is field 'a'","b":"this is field 'b'","c":"this
is field 'c'"}
After excluding: {}
```
In this example we're creating a complement of `excluded` (fields `a`, `b`
and `c`) regarding set `included` (the default fields `a`, `b` and `c`), which
will result in an empty set, or, in other words, nothing to reflect. The
behavior per se will be the same, however, with this proposal, we'll be able to
override the `included` set. Therefore, I think instead of throwing an
exception, we should add an explanation in the documentation about it and let
the users decide how to handle it.
If this is proposal is not valid and we proceed with the exception proposal,
which cases should we consider to throw it? `included` and `excluded` are equal
or just by having one field of `included` in `excluded` should throw an
exception?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
