miho commented 7 years ago

Collection API Proposal

This proposal addresses the following issues:

1. CollectionChange & Changed Elements:

List changes get indices as well as elements, getFrom(), getTo() were not sufficient. The event itself contains a merged set of changes. This supersedes the evt.changes() stream/list that would allow to merge changes manually. There's just one change set for added elements and one for removed elements with the additional possibility to check whether elements were replaced.

2. Generics & Lower Bounds

Previously, no lower bound was defined for listeners which did not support a plain collection change listener on observable lists. Maybe I don't get it right? To me it seems that a custom observable collection should be implemented like this:

Example:

/**
 * TODO
 * @author Hendrik Ebbers
 */
public interface ObservableCollection<E, C extends ObservableCollection<E, C, ?>, L extends CollectionChange<E, C>> extends Collection<E> {

    Subscription onChanged(CollectionChangeListener<? super E, C, L> listener);

}

class MyList<T> extends AbstractList<T> implements ObservableCollection<T, ObservableList<T>, CollectionChange<T, ObservableList<T>>> {

    @Override
    public Subscription onChanged(CollectionChangeListener<? super T, ObservableList<T>, CollectionChange<T, ObservableList<T>>> listener) {
        throw new UnsupportedOperationException("Bad, since it only supports list listeners and not collection listeners");
    }

    @Override
    public T get(int index) {
        throw new UnsupportedOperationException("Not supported yet.");
    }

    @Override
    public int size() {
        throw new UnsupportedOperationException("Not supported yet.");
    }    
}

TODOs

think about current limitations of lower bounds (only wildcards possible)
is there an alternative design that prevents wildcards but allows lower bounds?

miho commented 7 years ago

The current collection API proposal is now fully implemented for lists as part of VCollections. As soon as Maps and Sets are added, I will add support for them as well.

hendrikebbers commented 7 years ago

think about current limitations of lower bounds (only wildcards possible) is there an alternative design that prevents wildcards but allows lower bounds?

@miho can you describe this more deeply? I do not really understand what you mean...

miho commented 7 years ago

Hi Hendrik,

<lang:german> ich hoffe, dir geht's wieder gut :) </lang:german>

I don't like the fact that lower bounds only work on wildcards. Sometimes one looses the type information, e.g., when using elements in a collection with lower bound wildcard argument.

I just added the comment because I was not sure whether I missed a concept that would allow lower bounds without wildcards. But I think I didn't.

Regards, Michael

HanSolo commented 7 years ago

I would personally prefer value instead of newValue...just my 0.02€ ;)

hendrikebbers commented 7 years ago

@HanSolo interesting. I currently had a look at the property API of Swift (https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID254). Here they provide a willSet(...) and didSet(...) while in the willSet(...) you can access newValue, in didSet(...) it is simply called value. Maybe we should think about something like a willSet(...) listener that can be used for validation etc. Based on some discussions I would currently prefer:

1 listener type that will be called before the change. This listener will be called always (even if new value is equals old value). This listeners needs to have access to the old and new values. Maybe this can return a boolean value to interrupt the change based on validation etc.
1 listener type that will be called after the change. This listener will only be called if the value really changed (old != new). Here you can access the value and the old value.

What do you think. And yes, this is not the right please for this discussion and based on this I created https://github.com/guigarage/ObserverPattern/issues/2 So should discuss this point in the issue ;)

hendrikebbers commented 7 years ago

@miho <lang:german> Naja, Erkältung halt. Was soll man da machen... Aber danke der Nachfrage :) </lang:german>

guigarage / ObserverPattern