_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.
In object-oriented (O.O.) style programming, we see the “dot” between objects and
<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:
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
<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: