This is a somewhat general API interface design question and I am still wondering about the idiomatic “Julian” way of formulating it, so I thought I would ask here.
Suppose I have a vocabulary of verbs
h, which operate on some objects. These operations can either be lazy or eager (think eg
Iterators.filter). Both the lazy and the eager versions can be advantageous, and the user should feel free to decide when to actually instantiate intermediate objects (eg after benchmarking/profiling, suppose there is no good general answer because it depends on dimensions etc).
I can imagine various approaches:
using a wrapper type for the lazy version, use the capitalized type name for that, and the small letter version for the eager one. Eg
f. This can be neat, but exposes the implementation (perhaps the user should not care about the wrapper type).
put the lazy and eager versions in submodules, eg
ThatModule.Lazy.f. This can be cumbersome and confusing, and precludes having both in the same namespace.
govern lazyness with a keyword, eg
f(x; lazy = true). This is not type stable (unless we rely on constant propagation).
What would you recommend?