ListEvent & the deleted element

I'm working on making the deleted element available in every ListEvent. The difficult part is providing that value when the EventList is describing its change to its listeners via our ListEventAssembler API.

The ListEventAssembler and ListEvent provide a lot of functionality that developers don't even have to think about:

• When describing a change you can mark elements as deleted in any order you like. But the recipient EventList always receives its events in increasing order. This is useful for classes like SortedList which naturally scrambles the order of its input events.
• When describing a change, you can mark an element as inserted, and then later mark that same element as deleted. ListEventAssembler will reduce this to a no-op. This is useful for RangeList, which internally handles the changes before readjusting its range offset.

Providing the deleted element led to some interesting code today. Suppose we receive the following change notifications:

updates.beginEvent();
updates.elementUpdated(5, "alpha");
updates.elementRemoved(5, "beta");
updates.commitEvent();

The elementUpdated() call means that the value at index 5 used to be 'alpha' and now it's something new. The elementRemoved() call means that the value at index 5 has now been deleted, and it's initial value was "beta".

In this case ListEventAssembler merges these two calls:

updates.beginEvent();
updates.elementRemoved(5, "alpha");
updates.commitEvent();

The 'alpha' stands because it happened first, but the 'remove' stands because it happened last. It's counterintuitive, but it is exactly what the ListEventListener expects!

# posted by Jesse Wilson on Saturday, September 23, 2006