Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: _.oneArg, possibly _.twoArgs and/or _.limitArgs #225

Open
jgonggrijp opened this issue Aug 7, 2020 · 8 comments
Open

Suggestion: _.oneArg, possibly _.twoArgs and/or _.limitArgs #225

jgonggrijp opened this issue Aug 7, 2020 · 8 comments
Labels
after modules This should be postponed until after modularization (temporary label, see #220) enhancement

Comments

@jgonggrijp
Copy link
Contributor

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

@jgonggrijp jgonggrijp added enhancement after modules This should be postponed until after modularization (temporary label, see #220) labels Aug 7, 2020
@yashshah1
Copy link

Can I take this up?

@sktguha
Copy link

sktguha commented Aug 22, 2020

So @jgonggrijp woud it not be possible to isolate the _.ary function from lodash and use that itself ?

@jgonggrijp
Copy link
Contributor Author

@yashshah1

Can I take this up?

You can! Though it saves effort if you wait until after modularization, see #220.

@jgonggrijp
Copy link
Contributor Author

@sktguha

So @jgonggrijp woud it not be possible to isolate the _.ary function from lodash and use that itself ?

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
Copy link

@yashshah1

You can! Though it saves effort if you wait until after modularization, see #220.

@jgonggrijp sounds good. Is there any timeline on that?

Also, additionally is there any help required?

@jgonggrijp
Copy link
Contributor Author

@yashshah1

Is there any timeline on that?

Not really, but just to give you an impression:

  • I want to finish the Underscore 1.11 release before starting to concentrate on Contrib. I expect to reach that point in a week or so.
  • All the "before modules" issues and PRs have to be addressed before I can start modularizing. I think this would take at most a few weeks.
  • Modularization itself will probably take in the order of several weeks as well.

Also, additionally is there any help required?

Not required but certainly welcome: before modules This needs to be tackled before modularization (temporary label, see #220) .

@sktguha
Copy link

sktguha commented Aug 22, 2020

@yashshah1 we can collaborate on this :). Let me know if you have any ideas on this

@sktguha
Copy link

sktguha commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
after modules This should be postponed until after modularization (temporary label, see #220) enhancement
Projects
None yet
Development

No branches or pull requests

3 participants