Context trait design conventions

[bvssvni]

Context traits should be designed to be input-only.

The rationale is that many operations are valid for different representations of data. The different representations does not compose easily down into something that can be read from the context and used in a separate computation from the type.

For example, Transform2d does not provide methods for reading information out from the context. The default methods can only use simplified input-only operations.

[bvssvni]

This comes with a cost of duplicate code when there are lot of contexts that share the same representation. It is particularly painful for Transform2d and RelativeColor. Many contexts uses Matrix2d and Color. If this could be read out it would be easier to compose if one could read out the data and construct a new context by handling the computation externally.

Yet they both have use cases where the representation might be different:

• 3D matrix
• gradient

It makes no sense to ask a gradient which "color" it has, because it has two colors. It might make sense to ask a 3D matrix which 2D matrix it has, but it does not make sense to construct a new context with a modified 2D matrix when the context is 3D.

[bvssvni]

When a lot of contexts shares the same representation, one can use this #222 pattern to simplify the code.

At the moment Rust infer this pattern over to all types, which prevents it from being useful when there are more than one representation, but there is an RFC in process that will fix this rust-lang/rfcs#48