HI

I think your change is a good idea, but I don't really like using null
as an indicator of something special.
It sounds like an invitation to make mistakes about when the parameter
is or is not useful.

Why don't we just make this a special case and drop the "previous"
parameters?
I can't see many callers wanting to make use of it, and they could
always keep track of it themselves if they really need to.

-- Noel

Greg Brown wrote:
> Hi all,
>
> I am thinking about making a change to how selection change events are fired 
> and I would like to hear your feedback. Currently, selection change events 
> are fired only when an explicit call has been made that affects the 
> selection. 
>
> For example, in ListView, calling either setSelectedRanges() or 
> clearSelection() will fire this event. However, an operation that indirectly 
> changes the selection state (such as adding or removing an item from the 
> ListView's model data) does not trigger an event. This was originally done by 
> design - selectedRangesChanged() includes the previous selection as an 
> argument, and we didn't want to have to manually re-construct that every time 
> the selection changed as a side effect of a model change:
>
>   public void selectedRangesChanged(ListView listView, Sequence<Span> 
> previousSelectedRanges);
>
> However, in practice, I have found this to be a bit challenging. More than 
> once I have registered a selection change listener expecting to receive 
> notification of all selection changes, forgetting that it is not designed 
> that way. If I am getting tripped up by this, I'm guessing that other 
> developers might be as well.
>
> So, I am proposing that components that maintain a selection state also fire 
> selection change events when the selection changes indirectly. In this case, 
> a null value would be passed for the previous selection. This will save the 
> effort of re-constructing the previous selection info and will give the 
> listener additional information about the nature of the change (i.e. null == 
> indirect state change).
>
> Please let me know what you think.
>
> Thanks for your input,
> Greg
>
>
>   

Reply via email to