You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible to make the code for merge tactics generic (so it can be used for Map and IntMap without duplication, and could also be used for other map-like data structures in other libraries), and to increase the safety in doing so.
I have created a repository containing both an implementation and a fairly lengthy explanation of how it works.
There are some decisions to be made about how to do it: most noticeably, there is a dependency upon Kinoshita's witherable library. I have demonstrated that this library can be trimmed down heavily, but there are still several possibilities for where it should go: it could go into base, into containers, or remain as a separate library (which would then need to be a dependency of containers).
@tomjaguarpaw has spent some time reviewing these ideas (I'm grateful for feedback on an earlier version); he may be willing to make his thoughts known.
The text was updated successfully, but these errors were encountered:
Yes, I found @jcranch's write up excellent and I'd recommend it to the containers maintainers. His idea could prove to be a very nice and practical way of generalising merge functionality.
It is possible to make the code for merge tactics generic (so it can be used for Map and IntMap without duplication, and could also be used for other map-like data structures in other libraries), and to increase the safety in doing so.
I have created a repository containing both an implementation and a fairly lengthy explanation of how it works.
There are some decisions to be made about how to do it: most noticeably, there is a dependency upon Kinoshita's witherable library. I have demonstrated that this library can be trimmed down heavily, but there are still several possibilities for where it should go: it could go into base, into containers, or remain as a separate library (which would then need to be a dependency of containers).
@tomjaguarpaw has spent some time reviewing these ideas (I'm grateful for feedback on an earlier version); he may be willing to make his thoughts known.
The text was updated successfully, but these errors were encountered: