On Fri, 23 Jun 2023 21:57:03 GMT, Kevin Rushforth <k...@openjdk.org> 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