Open
Description
@sktguha over in jashkenas/underscore#2871:
I suggest adding a new function called oneArg to underscore. It wraps a function and allows it to be called with one argument only and ignores rest of the arguments.
Implementation:
const oneArg = fn => arg => fn(arg);
usage:
Before oneArg:
['34','11','19','199','201'].map(parseInt); // returns [34, NaN, 1, 1, 33]
After oneArg:
const safeParseInt = oneArg(parseInt); ['34','11','19','199','201'].map(safeParseInt) // returns [34, 11, 19, 199, 201]
When implementing this, we may want to alias _.oneArg
to _.unary
and _.limitArgs
to _.ary
in order to not create more distance from Lodash than necessary.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
yashshah1 commentedon Aug 21, 2020
Can I take this up?
sktguha commentedon Aug 22, 2020
So @jgonggrijp woud it not be possible to isolate the _.ary function from lodash and use that itself ?
jgonggrijp commentedon Aug 22, 2020
@yashshah1
You can! Though it saves effort if you wait until after modularization, see #220.
jgonggrijp commentedon Aug 22, 2020
@sktguha
In principle, yes. In practice, borrowing code from Lodash tends to be undesirable because the code is very verbose and over-engineered. I just took a look to check and it confirmed my suspicion:
_.ary
and_.unary
are not directly defined anywhere, but instead generated by a complicated machinery that also generates_.partial
,_.curry
etcetera (start reading here to see what I mean). I haven't traced all the functions that are involved, but it wouldn't be too far-fetched to state that borrowing_.ary
from Lodash might double the size size of Underscore-contrib.Even if the code size isn't as dramatic, writing the code yourself is certainly much easier, as your own opening post demonstrated.
yashshah1 commentedon Aug 22, 2020
@jgonggrijp sounds good. Is there any timeline on that?
Also, additionally is there any help required?
jgonggrijp commentedon Aug 22, 2020
@yashshah1
Not really, but just to give you an impression:
Not required but certainly welcome: before modulesThis needs to be tackled before modularization (temporary label, see #220)
.
sktguha commentedon Aug 22, 2020
@yashshah1 we can collaborate on this :). Let me know if you have any ideas on this
sktguha commentedon Aug 22, 2020
@jgonggrijp thanks for the quick and detailed response.
So i guess creating the _.ary function will be first step and then creating the oneArg and twoArg and limitArgs functions from that .
If you have better names in mind we can use that.
Actually I think using unary is better, to maintain uniformity with lodash.