ListChangeListener

[Daniel Zwolenski]

Resending this as I forgot to reply all  (again).


On 09/12/2011, at 3:38 PM, Daniel Zwolenski <zonski at googlemail.com> wrote:

> I'd quite like to see a simplification of list change handling, as I agree this can be a little cumbersome to implement. Given the API is already in place, perhaps your suggestion could be achieved just by having an AbstractListChangeListener (or following the Swing naming pattern, a ListChangeListenerAdapter), that provided the default looping implementation and called out to abstract methods on itself?
> 
> Then you could probably just do something like the following (this is just indicative, there'd be more to it than this, I'm sure): 
> 
> myObservableList.addListener(new ListChangeListenerAdapter<E>() {
>         void itemAdded(int index, E item) {
>             // handle add
>         }    
> 
>         void itemRemoved(int index, E item) {
>             // handle remove
>         }    
> 
>         void itemUpdated(int index, E item) {
>             // handle update
>         }    
>     }
> }
> 
> Would that work?
> 
> 
> On Fri, Dec 9, 2011 at 6:07 AM, Gaja Sutra <gajasutra at gmail.com> wrote:
> When trying to write the collections needed by my application and lacking in JavaFX runtime, I have found difficult to use ListChangeListener, because the code to write (the while loop on each change with tests of operation type) is difficult to read. I suggest the following addition to API:
> 
> 1) In ObservableList<E> add the following new method and create the corresponding interface:
> 
> |public void addListener(ListChangeHandler<? super E> obs);|
> 
> |public interface ListChangeHandler<E> {
>    public void begin();
>    public void addedItem(int index, E addedItem);
>    public void addedItems(int from, int to, List<? extends E> readOnlyAddedItems);
>    // ReadOnlyIntList wrap the int[] to be read-only
>    public void swapped(int from, int to, ReadOnlyIntList permutation);
>    public void removedItems(int index, int size, List<? extends E> readOnlyDeletedItems);
>    public void removedItem(int index, E removedItem);
>    public void end();
> }
> |
> 
> 2) Provide a class of utilities methods for ListChangeHandler giving implementation of methods by delegating to it:
> |public class ListChangeUtils {
>    public static void addedItems(ListChangeHandler handler, int from, int to, List<? extends E> readOnlyAddedItems) {
>        for (int i = from; i<to; i++) {
>            handler.addedItem(i, readOnlyAddedItems.get(i-from));
>        }
>    }
> }
> |
> 
> 3) In Java8, with defenders methods <http://cr.openjdk.java.net/%7Ebriangoetz/lambda/Defender%20Methods%20v4.pdf>, add default implementations for all methods excepted the following four methods:
> 
> |public interface ListChangeHandler<E> {
>    public void begin();
>    public void addedItem(int index, E addedItem);
>    public void removedItem(int index, E removedItem);
>    public void end();
> }|
> 
> by having code like this, for other methods, in the preceding interface:
> 
> |    public void addedItems(int from, int to, List<? extends E> readOnlyAddedItems) default ListChangeUtils.||addedItems||;
> |
> 
> 4) Conclusion: I think this will give correct performance by allowing, like with ListChangeListener, to have a specialized handler receiving directly the addition of multiple items (if it support this feature). But if the handler can not have optimized path for this case it will need in current Java to implement addedItems by calling |ListChangeUtils.addedItems(this, from, to, readOnlyAddedItems)| or in Java8 by doing nothing (automatically supported by defender method). This is the symmetric model for receiving notification of changes, like com.sun.javafx.collections.IterableChangeBuilder is for creating changes notification.
> 
> For code readability, I think having one method for each type of operation on list will be much more clean and readable, because the while loop will disappear and each type of operation will correspond to one method of handler separated from others.
> 
> Thanks for your opinions,
> Daniel.
> 
>