operators are functions which accept an iterable and return an iterable (i.e. they are infinitely chainable/pipeable);
enders are functions which accept and interable and return an arbitrary thing (i.e. they can appear only at the end of a chain);
static functions accept an arbitrary thing and return an arbitrary thing, commonly an iterable and sometimes something related to iterables (e.g. a tuple of iterables, a map of iterables, etc).
However, enders Ender<T, U> are just a more convenient way to write static functions which accept exactly one iterable, and optionally more parameters.
For example, a static function for computing the size of an iterable has signature (iterable: Iterable<T>, options: any) => number, and is written as follows:
Note that “options“ have been added just to make the example more complete. Imagine a more complex operation. An accompanying ender would be written as follows, which is more readable:
Here, I propose ditching enders as separate entities and introducing a catch-all “ender” called j.andFinally which accepts a function which accepts an iterable as the first parameter, and passes the other parameters into the static function.
With enders out of the way, we only have regular operators and static operators, which could then be distinguished by naming convention instead of by conflusing and ugly single-letter namespaces e and s.
I forgot about generators, the fourth type of functions. However, it seems like generators are simply a specific type of static functions (they accept anything and return an iterable).
Currently, there are three types of functions:
However, enders
Ender<T, U>
are just a more convenient way to write static functions which accept exactly one iterable, and optionally more parameters.For example, a static function for computing the size of an iterable has signature
(iterable: Iterable<T>, options: any) => number
, and is written as follows:Note that “options“ have been added just to make the example more complete. Imagine a more complex operation. An accompanying ender would be written as follows, which is more readable:
Here, I propose ditching enders as separate entities and introducing a catch-all “ender” called
j.andFinally
which accepts a function which accepts an iterable as the first parameter, and passes the other parameters into the static function.With enders out of the way, we only have regular operators and static operators, which could then be distinguished by naming convention instead of by conflusing and ugly single-letter namespaces
e
ands
.