kscience/kmath
9
0
Fork 1
Code Issues Pull Requests 6 Packages Projects Releases 16 Wiki Activity

add another alternative for specifying context

Browse Source
This commit is contained in:
breandan.considine 2018-12-28 23:50:04 -05:00
parent 350151b62a
commit a76dac633b
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/contexts.md
View File

@ -50,9 +50,24 @@ In KMath, contexts are not only responsible for operations, but also for raw obj
## Other possibilities
### Type classes
An obvious candidate to get more or less the same functionality is the type class, which allows one to bind a behavior to
a specific type without modifying the type itself. On the plus side, type classes do not require explicit context
declaration, so the code looks cleaner. On the minus side, if there are different sets of behaviors for the same types,
it is impossible to combine them into one module. Also, unlike type classes, context can have parameters or even
state. For example in KMath, sizes and strides for `NDElement` or `Matrix` could be moved to context to optimize
performance in case of a large amount of structures.
performance in case of a large amount of structures.
### Wildcard imports and importing-on-demand
Sometimes, one may wish to use a single context throughout a file. In this case, is possible to import all members
from a package or file, via `import context.complex.*`. Effectively, this is the same as enclosing an entire file
with a single context. However when using multiple contexts, this technique can introduce operator ambiguity, due to
namespace pollution. If there are multiple scoped contexts which define the same operation, it is still possible to
to import specific operations as needed, without using an explicit context with extension functions, for example:
```
import context.complex.op1
import context.quaternion.op2
```