Return to Answer

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> as input instead of T[,]. This is probably the cleanest alternative, but I guess it will mean some code duplication in your extension library, since T[,] and IGrid<T> don't have a common interface.

• to avoid the code duplication, you could write a conversion method from IGrid<T> to T[,], but this will have the drawback of making additional copies of the data. You could use this with my first suggestion to create adapter methods to avoid the code-duplication:

     T[,] Transpose(this IGrid<T> value)
     {
          return ConvertIGridToArray(value).Transpose();
     }
  

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

Currently, I don't see a way to avoid the code duplication and the additional copying and the loss of immutability all three - pick your choice.

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative, since it is less memory consuming. Note further that if you want your transformation methods work on something like an Heightmap class, they cannot deliver a new Heightmap object directly, you will have to do some type conversion either. An in-place transformation would not have that problem, it could operate on the internal T[,] of the Heightmap object directly.

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> as input instead of T[,]. This is probably the cleanest alternative, but I guess if you want to keep and maintain the T[,] variant, too, it will mean some code duplication in your extension library, since T[,] and IGrid<T> don't have a common interface.

• to avoid the code duplication, you could write a conversion method from IGrid<T> to T[,], but this will have the drawback of making additional copies of the data. You could use this with my first suggestion to create adapter methods to avoid the code-duplication:

     T[,] Transpose(this IGrid<T> value)
     {
          return ConvertIGridToArray(value).Transpose();
     }
  

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

Currently, I don't see a way to avoid the code duplication and the additional copying and the loss of immutability all three - pick your choice.

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative, since it is less memory consuming. Note further that if you want your transformation methods work on something like an Heightmap class, they cannot deliver a new Heightmap object directly, you will have to do some type conversion either. An in-place transformation would not have that problem, it could operate on the internal T[,] of the Heightmap object directly.

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> as input instead of T[,]

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

• write a conversion method from IGrid<T> to T[,] (note that this will imply making additional copies of the data).

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative, since it is less memory consuming. Note further that if you want your transformation methods work on something like an Heightmap class, they cannot deliver a new Heightmap object directly, you will have to do some type conversion either. An in-place transformation would not have that problem, it could operate on the internal T[,] of the Heightmap object directly.

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> as input instead of T[,]. This is probably the cleanest alternative, but I guess it will mean some code duplication in your extension library, since T[,] and IGrid<T> don't have a common interface.

• to avoid the code duplication, you could write a conversion method from IGrid<T> to T[,], but this will have the drawback of making additional copies of the data. You could use this with my first suggestion to create adapter methods to avoid the code-duplication:

     T[,] Transpose(this IGrid<T> value)
     {
          return ConvertIGridToArray(value).Transpose();
     }
  

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

Currently, I don't see a way to avoid the code duplication and the additional copying and the loss of immutability all three - pick your choice.

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative, since it is less memory consuming. Note further that if you want your transformation methods work on something like an Heightmap class, they cannot deliver a new Heightmap object directly, you will have to do some type conversion either. An in-place transformation would not have that problem, it could operate on the internal T[,] of the Heightmap object directly.

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> instead of T[,]

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

• write a conversion method from IGrid<T> to T[,] (note that this will imply making an additional copy of the data when applying it.

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative.

There is no guarantee that a client implementing IGrid<T> does actually use an 2D array T[,] for the implementation. So without changing something, you cannot expect to make your extension library work "out of the box" on IGrid<T>. IMHO you have the following options:

• change (or extend) the interface of your Transformation class to use IGrid<T> as input instead of T[,]

• extend IGrid<T> to provide access to underlying T[,], with the drawback of loosing immutability (which forces any client to use a T[,] internally)

• write a conversion method from IGrid<T> to T[,] (note that this will imply making additional copies of the data).

Note that for big arrays, immutability maybe not the optimal design for your transformation operations, without immutability they could be implemented in-place, which is sometimes the better alternative, since it is less memory consuming. Note further that if you want your transformation methods work on something like an Heightmap class, they cannot deliver a new Heightmap object directly, you will have to do some type conversion either. An in-place transformation would not have that problem, it could operate on the internal T[,] of the Heightmap object directly.