Idea Graveyard

Following the example of guava, we collect here ideas we rejected throughout the development of tensorics and to give a reasonable good explanation for each of them.

Upper bound type parameter for Coordinates

Analogous to a java map, which specifies an upper bound parameter for the type of keys, it seems to be natural to do the same for coordinates in tensorics. E.g. something like:

class Tensor<C,V> {...}

Indeed, this was our first try. From this we gained the following experience:

• It turned out that dragging this type parameter around through all the transformations and calculation turned out to led very soon to 'generics hell'.
• Whenever more than one type was used as coordinates (which is the sole purpose of our tensors - otherwise a simple map would do the job), and if e.g. existing types were to be used and types of different domains are combined (e.g. Instance in a combination with a custom object), one usually anyway ended up in using 'Object' as an upper bound.

Therefore, we decided to keep it simple: A coordinate can be of any type.

The disadvantage of this decision of course comes with a cost: All type checks on coordinates can only be done at runtime (while the compile time checks only were of limited use anyhow because of the above reason). We are trying to be very strict in such checks and fail as fast as possible. We feel that this is reasonable compromise to provide all the intended functionality with a reasonable maintainable codebase.

Another attempt for limited typed support was discussed in Issue #36...