On Fri, 18 Mar 2022 11:12:55 GMT, Tom Schindl <tschi...@openjdk.org> wrote:
>> John Hendrikx has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Reword flat map docs a bit and fixed a link
>> - Add missing javadoc tags
>> - Clean up docs in Subscription
>> - Fix code blocks
>> - Add line feed at last line where it was missing
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java
> line 57:
>
>> 55: * Cancels this subscription.
>> 56: */
>> 57: void unsubscribe();
>
> to me `unsubscribe` feels not natural, I'm not unsubscribing a `Subscription`
> but I'm eg disposing it, hence to me `dispose` would feel better but I'm not
> a native speaker.
>
> Another pattern I see often is that I store a subscription in a field and
> recreate it under certain conditions:
>
>
> private Subscription mySubscription;
>
> void refresh() {
> if( this.mySubscription != null ) {
> this.mySubscription.dispos();
> }
> this.mySubscription = ....
> }
>
>
> if Subscription would provide
>
> ```java
> static void dispose(Subscription subscription) {
> if( subscription != null ) {
> subscription.dispose();
> }
> }
>
>
> this would safe the user a null-check.
This API is not going to be public for now, so we still have some time to work
out the details. Another option would be to use `cancel` instead of
`unsubscribe` or `dispose` (an internal class in the JDK uses `cancel`, reactfx
uses `unsubcribe`).
Subscription.dispose(subscription);
I'm not sure how I feel about a helper method like that to do a `null` check; I
feel that `null` checks are the callers responsibility (in almost all
situations). It is also not really OO, it feels like `void *x = malloc(1000)`
and `free(x)` instead of getting an object and calling `free` on the object.
-------------
PR: https://git.openjdk.java.net/jfx/pull/675
