_part_
_part_, a meta-utility, proposes a pattern for creating utility functions from native methods using a more functional programming style. However, rather than settle the “argument” of function-first versus receiver-first, _part_ offers a simple, yet intuitive, way to use both styles.
Patterns
In object-oriented (O.O.) style programming, we see the “dot” between objects and
their methods: <subject>.<verb>
. The subject-verb (or receiver-method) pattern
works well when you know the receiver, it has said method, and it does not change.
But in other situations, you may prefer a functional, or point-free, style: <verb>(<subject>)
.
Most commonly, developers in loosely-typed languages, like JavaScript, use this pattern while
mapping over several objects.
Arguments over arguments
While functional programmers agree on the power and utility of their programming style
over traditional OO, there exists a fundamental argument over how to pass parameters
to these functions. In the OO world, we simply add arguments to the end of the
code sentence, <subject>.<verb>(<predicate>)
. In the functional world, which do
you prefer, receiver-first <verb>(<subject>, <predicate>)
or predicate-first
<verb>(<predicate>, <subject>)
? Does your preference change?
In many situations, like the mapping situation mentioned above, the method takes a function argument. When that argument precedes the receiver, you used the “function-first” approach. Because other methods, like reduce, may have additional parameters, many functional programmers use the object-first approach. This way, they do not need to decide where additional parameters go: before or after the predicate function.
Why not both?
In _part_, you use typical OO functions (like the ones in native prototypes) to create two functional counterparts, “left-part” and “right-part”, which partially apply the receiver or parameters respectively.
The OO map example:
The “left-part” version:
The “right-part” version:
Include additional arguments, such as when using reduce on either side: