Naming

[benjdlambert]

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 or parl or even papply.

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 and partial would suffice no? or partialLeft and partialRight?

const quote = (name, say) => {
    console.log(`my name is ${name}, ${say}`);
}

const adam = quote.partial('adam');
adam('I reject your reality, and substitute my own');

// my name is adam, I reject your reality, and substitute my own

Thoughts?

/blam

[Alexsey]

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

[zackschuster]

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.

[alexandradeas]

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.

[elycruz]

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);

[elycruz]

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)

[elycruz]

Also, about "+1 for partialApply" as @zackschuster pointed it sticks with the language's overall naming scheme.

[elycruz]

@benjdlambert "(Cue the masses that I missed)" most of the Math object's method (lol) 👍

[alecperkins]

Additional prior art of sorts: lodash’s _.partial and _.partialRight utilities.

[elycruz]

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).