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

Should all operators be functions-that-return-functions? #2

Open
njlr opened this issue Feb 21, 2018 · 0 comments
Open

Should all operators be functions-that-return-functions? #2

njlr opened this issue Feb 21, 2018 · 0 comments
Labels
question Further information is requested

Comments

@njlr
Copy link
Owner

njlr commented Feb 21, 2018

To achieve a friendly syntax for operators with parameters, we use a pattern where the library provides a function-that-returns-a-function.

> seq.map
[Function]

> seq.map(x => x * 2)
[Function]

We do not do this for operators without parameters.

> seq.toArray
[Function]

Some operators have parameters, but each has a default value:

> seq.unique
[Function]

> seq.unique()
[Function]

This makes operator usage somewhat inconsistent:

[ 1, 2, 3 ]
  |> map(x => x * 2) // Parentheses to wrap parameters
  |> unique() // Parentheses required because we have default arguments
  |> toArray; // No parentheses, because this is not a function-that-returns-a-function

Perhaps it should look like this instead?

[ 1, 2, 3 ]
  |> map(x => x * 2) 
  |> unique() 
  |> toArray(); // Parentheses required for all operators
@njlr njlr added the question Further information is requested label Feb 21, 2018
@njlr njlr changed the title Should all operators be functions-that-returns-functions? Should all operators be functions-that-return-functions? Feb 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant