Hi Semyon,
I'm felling guilty & would like to apologise once again for nit-picking.
The ButtonModel basically defines some observable properties which do
not otherwise have behaviour (unless someone has gone and created some
horrendous mix-in abomination with it - unlikely). So I am being
unreasonable to be concerned about this point.
Please do proceed with either the original text or your suggestion! :-)
Kind regards,
Luke
On 03/07/2017 12:42, Luke wrote:
Hi Semyon,
On 30/06/2017 17:45, Semyon Sadetsky wrote:
I would change the spec to
+ * @return the <code>ButtonGroup</code> that the button belongs
to or null otherwise
Because if the getter returns null the button doesn't actually belong
to any group, and this is true for both legacy and after
implementations.
But the current spec looks ok to me as well.
FYI: this sentence contains the logical mistake that I could see users
falling for. A legacy ButtonModel may continue to hold a non-null
ButtonGroup reference and implement its behaviour accordingly: that it
is now in a group. A caller that assumes getGroup() == null means
_only_ that the model is not in a group would be mislead.
Occasionally callers might need to handle the legacy case to ensure
everything behaves consistently - such as by maintaining their own
reference to the ButtonGroup externally. But I accept the need to
distinguish would be seldom.
I'm sorry I was not able to describe this better in my earlier emails
- only by discussing it I reached clarity on what initially "bugged"
me about the default implementation myself.
Anyway, I will leave this thought with you.
Kind regards,
Luke
