Open benjdlambert opened 8 years ago
This is not a problem when we talking about usage like in your example. Problem occurs in case of usage in inline functions that's become
const result = data.map(process.partialRight(options))
that is already 59 symbols long even with meaningless names and without starting indent. And it is really a simple case.
par
and parl
(or any other) are feting current JavaScript infrastructure in the same way as arrow functions that makes inline function usage much more pleasant
I don't think shaving 3-8 symbols per declaration is the right call when it breaks from the language's lexical standard. Sure, we'd all like JavaScript to be less noisy, but "my one-liners are too long" is not, in my opinion, a good enough excuse for tossing a unicorn into the language's API map -- especially when partial
/partialRight
already has a linguistic corollary in the Array
prototype's reduce
/reduceRight
methods.
It's a whole extra 8 bytes! For a server dealing with 1000 rpm; that's a whole 4Gb of data per year for each usage! :trollface:
I agree generally with what's been mentioned; consistency matters and the only case I can think of an abbreviation being used in the standard lib is with the Eval object. JS tends to use acronyms.
I agree with @alex-deas, @zackschuster and @benjdlambert and also want to add that in truly functional programming model most folks would probably put it in a function which will then make all the invocations shorter (when the code is minified also) (also for composing even the partial function itself into other compositions) (no?):
const partial = (fn, ...args) => fn.partial(...args);
I gave this more thought and have discovered that 1. The naming is not that important IMO (though I +1 partialApply
(It's readable shrugs). 2. We would probably need a flip
method instead of a pApplyRight
method (flip
would combine with partialApply
to, in essence, facilitate performing a partialApplyRight
). Also, something else to think about is the fact that apply
takes an array as it's second parameter and how having a partialApply
method might be confusing to some users who know how apply
works but don't know anything about partial application. Furthermore, the naming of partialApply
might need to be put further through the paces since in comparison to apply
and call
, partialApply
actually performs more like a partialCall
(due to not taking an array of args (as mentioned before) mindblow? (lol)
Also, about "+1 for partialApply
" as @zackschuster pointed it sticks with the language's overall naming scheme.
@benjdlambert "(Cue the masses that I missed)" most of the Math
object's method (lol) 👍
Additional prior art of sorts: lodash’s _.partial
and _.partialRight
utilities.
Chiming in after seeing the post again. Going back on my idea of needing a flip
implementation to facilitate partialApplyRight
instead we should just shoot for it (partialApplyRight
). Also for partialApply
it doesn't matter that apply
takes an array for args and partialApply
would take singular arguments (IMO).
Sorry to add yet another issue about the name, and maybe i've missed something - if I have, I apologise - but as regards to the name, why does it have to be something like
par
orparl
or evenpapply
.Those names don't fit at all with entire ethos of the language. I actually cannot really recall any method in the standard library which has some form of abbreviation in the method signature. (Cue the masses that I missed)
The only one I can think of is
isNaN
It just feels like
partialRight
andpartial
would suffice no? orpartialLeft
andpartialRight
?Thoughts?
/blam