At present, the "Capacity Control" system used by TLKListBase<T> and its descendants will dynamically increase the Capacity when the Threshold is reached. That's as designed and will remain that way (it makes sense).
However, the recent addition of an automatic Compaction upon removal of items below a given Threshold presents something of an annoying issue.
If the implementing developer creates the List, then specifies an explicit Capacity for said list, they aren't going to want that capacity reducing if an Item is Removed.
This can easily be resolved by storing custom capacities alongside the current one, and having the Capacity Control solution clamp the minimum compaction amount to that explicit Capacity value.
Simple enough to introduce, however this should be done only after issue #87, as the "Capacity Control" method is going to be separated from TLKListBase<T> so that alternative solutions can be dropped in on an instance-by-instance basis.
At present, the "Capacity Control" system used by
TLKListBase<T>
and its descendants will dynamically increase the Capacity when the Threshold is reached. That's as designed and will remain that way (it makes sense). However, the recent addition of an automatic Compaction upon removal of items below a given Threshold presents something of an annoying issue.If the implementing developer creates the List, then specifies an explicit Capacity for said list, they aren't going to want that capacity reducing if an Item is Removed.
This can easily be resolved by storing custom capacities alongside the current one, and having the Capacity Control solution clamp the minimum compaction amount to that explicit Capacity value.
Simple enough to introduce, however this should be done only after issue #87, as the "Capacity Control" method is going to be separated from
TLKListBase<T>
so that alternative solutions can be dropped in on an instance-by-instance basis.