ArrayHandleDecorator should support allocating/resizing arrays
ArrayHandleDecorator
is missing an important feature that prevents it from being used in many places where a verbose ArrayHandle
implementation is used. That is, it is unable to properly handle the Allocate
and Shrink
methods in ArrayHandle
.
The ArrayHandleDecorator
implementation of both of those methods is to simply ignore the request and happily do nothing. This is wrong in all cases.
ArrayHandleDecorator
should support 2 modes of operation: an array that can be resized and an array that cannot be resized. Each mode should have different behavior for Allocate
and Shrink
.
Resizable array
Some decorator arrays should be able to respond to an Allocate
and resize the underlying arrays. For example, ArrayHandleGroupVec
, which should be implementable as an ArrayHandleDecorator
, needs to be able to resize the underlying array handle to accommodate its behavior as an array of Vec
s. Several filters in VTK-m rely on this behavior.
In this case, both Allocate
and Shrink
need to have a way to allow the decorator implementation class to resize the decorated arrays and change the size that ArrayHandleDecorator
reports.
Non-resizable array
Some decorator arrays have no practical way to actually allocate or resize an array. For example, it makes little sense for an ArrayHandlePermutation
to get bigger since there would be no way to know what indices to use for the new items.
However, that does not mean that they should blindly accept any call to Allocate
or Shrink
. That is a recipe for disaster if code expects the array to have changed size but has not. Instead, the method should check to see if the requested size matches the current size. If they match, then return successfully. If they do not match, throw an exception.