On Fri, 23 Jun 2023 21:57:03 GMT, Kevin Rushforth <[email protected]> wrote:
>> On that same topic of naming methods:
>>
>> What do people think of `Subscription#unsubscribe`? Should it be `cancel`?
>> Something else? Okay as it is?
>>
>> Code example:
>>
>> if (subscription != null) {
>> subscription.unsubscribe();
>> subscription = null;
>> }
>
>> | invalidation | values | changes |
>> |---|---|---|
>> |`subscribe(Runnable)`(*)|`subscribe(Consumer)`(*)|`subscribe(BiConsumer)`(*)|
>> |`subscribeInvalidations(Runnable)`|`subscribeValues(Consumer)`|`subscribeChanges(BiConsumer)`|
>> |`invalidationsTo(Runnable)`|`valuesTo(Consumer)`|`changesTo(BiConsumer)`|
>>
>> (*) May limit future listener types that have same arity, but can still be a
>> good choice
>
> My preference is in the order you listed them. If we go with `subscribe`,
> using method name overloading, do want to add a future overload that takes a
> type with the same arity as one of the existing three, we can always assign a
> new name to that new method (since adding another overload wouldn't be source
> compatible, we would likely need a new name at that point).
>
> @nlisker @andy-goryachev-oracle @mstr2 - what do you think?
> On that same topic of naming methods:
>
> What do people think of `Subscription#unsubscribe`? Should it be `cancel`?
> Something else? Okay as it is?
OK as is. Especially if we go with one of the two choices with "subscribe" in
the name.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1240441669
