Breaking change - renaming old mutable setXX methods #191
Conversation
| @@ -196,7 +196,7 @@ public boolean cachingEnabled() { | |||
| * @param cachingEnabled {@code true} to enable caching, {@code false} otherwise | |||
| * @return a new data loader options instance for fluent coding | |||
| */ | |||
| public DataLoaderOptions setCachingEnabled(boolean cachingEnabled) { | |||
| public DataLoaderOptions withCachingEnabled(boolean cachingEnabled) { | |||
There was a problem hiding this comment.
how about making these static to discourage chaining and removing the newOptions function?
There was a problem hiding this comment.
Not sure what you mean by static. But while agree we should have made a compiler breaking change the first time (which we are now) I do still want to retain immutable options chaining.
There was a problem hiding this comment.
Chaining is good however even with this change you can still write
DataLoaderOptions options = DataLoaderOptions.newOptions()
.withMaxBatchSize(5);
options.withBatchingEnabled(false);
Which is breaking
I feel like instead if you remove newOptions() and swap to static the IDE will hint the bad pattern of static methods on the instance, no longer recommend chaining on the concrete instance and hint people towards chaining only on the builder
IDE hinting to not use the static methods on the instance which would break the behavior
IDE not suggesting chaining of the static methods
(It will allow you to explicitly type it out but won't suggest it and will warn if you do) This code is technically valid but i feel like we want to push people to the Builder since it exists now
Push people towards proper builder pattern
There was a problem hiding this comment.
Normally I dont mind options.setX(x).setY(y) but since we stuff up the API during the immutability change then we have created a muddy water situation
So you are right, we need to be more clear in this case because of the previous history
So I have deleted all the with method and now only have the builder. So every one has to move to a new place which is more sympathetic to immutability
Thanks for the feedback.
…lder pattern only
| this.valueCacheOptions = other.valueCacheOptions; | ||
| this.batchLoaderScheduler = other.batchLoaderScheduler; | ||
| this.instrumentation = other.instrumentation; | ||
| } |
There was a problem hiding this comment.
no point any longer and anyway lets use builders with this breaking change
| */ | ||
| public DataLoaderOptions setBatchingEnabled(boolean batchingEnabled) { | ||
| return builder().setBatchingEnabled(batchingEnabled).build(); | ||
| } |
There was a problem hiding this comment.
All the object -> mutate -> new object methods are removed and now only in the builder
| * | ||
| * @param batchingEnabled {@code true} to enable batch loading, {@code false} otherwise | ||
| * @return this builder for fluent coding | ||
| */ |
There was a problem hiding this comment.
doco all transferred from above set methods
#190
We changed the semantics of DataLoaderOption to be immutable but we didnt change the API signature and this led to confusion and the possibility of bugs where previously mutable calls not longer took effect
See the issue from more details
This now makes this a breaking change and will fail at compile time