So a implementation class should based on List to implement the interface, otherwise it should transform it's own data struct (such as Tree) to List.
Another cons for TypePool return list is:
When a caller get these three list, if it delete one item only in one list, there will be exception in future. The use of the three list is to get the pool size and delete items of specific class. I think it's better to provide two method named 'size' and 'unregister' to hide inner implementation details and protect inner data.
So, I think the finall TypePool interface could be:
<T> void register(Class<? extends T> clazz, ItemViewBinder<T, ?> binder,Linker<T> linker);
/**
* Unregister all items with specific class.
*/
void unregister(@NonNull Class<?> clazz);
/**
* Returns the number of items in this pool.
*/
int size();
int firstIndexOf(@NonNull Class<?> clazz);
/**
* Get the class at specific index.
*
* @param index the item index
* @return the class at specific index
* @throws IndexOutOfBoundsException if the index is out of range
*/
Class<?> getClass(int index);
ItemViewBinder<?, ?> getItemViewBinder(int index);
Linker<?> getLinker(int index);
What did I do:
If this request is accepted, I can make a merge request from my fork.
What kind of issue is this?
Info:
Description:
TypePool now define these three interface:
So a implementation class should based on List to implement the interface, otherwise it should transform it's own data struct (such as Tree) to List.
Another cons for TypePool return list is: When a caller get these three list, if it delete one item only in one list, there will be exception in future. The use of the three list is to get the pool size and delete items of specific class. I think it's better to provide two method named 'size' and 'unregister' to hide inner implementation details and protect inner data.
So, I think the finall TypePool interface could be:
What did I do:
If this request is accepted, I can make a merge request from my fork.