Skip to content
New issue

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

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

Already on GitHub? # 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.

# for free to join this conversation on GitHub. Already have an account? # 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