First step is to generically create a persistent vector implementation from any List definition that just happens to be the subset that readers actually implement. This supports all the readers as a proxy with most importantly the same memory characteristics as the base reader and is very little code for the win.
These offer key advantages over a generic readers - specifically implementation of correct hash and equality semantics over generic lists of types. This is a great step forward as APersistentVector also has a minimal high quality java.util.List implementation and as such will work out of the box with a wider range of existing software that readers with their extremely partial subset. It also may have the benefit that persistent vectors and readers will hash to the same bin in a hashtable.
The one caveat is at this level that binding should be loose and easy to fix between upstream software versions.
cnuernber
commented
4 years ago
First step is to generically create a persistent vector implementation from any List definition that just happens to be the subset that readers actually implement. This supports all the readers as a proxy with most importantly the same memory characteristics as the base reader and is very little code for the win.
These offer key advantages over a generic readers - specifically implementation of correct hash and equality semantics over generic lists of types. This is a great step forward as APersistentVector also has a minimal high quality java.util.List implementation and as such will work out of the box with a wider range of existing software that readers with their extremely partial subset. It also may have the benefit that persistent vectors and readers will hash to the same bin in a hashtable.
The one caveat is at this level that binding should be loose and easy to fix between upstream software versions.