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

Special case unary hack operator part 2 #266

Closed
cowboyd opened this issue Mar 15, 2022 · 2 comments
Closed

Special case unary hack operator part 2 #266

cowboyd opened this issue Mar 15, 2022 · 2 comments
Labels
question Further information is requested

Comments

@cowboyd
Copy link

cowboyd commented Mar 15, 2022

Apologies for creating a new issue. The old one was locked.

Originally posted by @js-choi in #260 (comment)

Could you clarify whether .match, .filter, and .forEach in your original example are object methods or non-method curried unary functions?

// The original post’s snippet.
stream.
  .match({ topic: 'available' }) // Is this a method call?
  .filter(status => ['started', 'exited'].includes(status.type))
  .forEach(function*(status) {
    yield send(status);
  }));
});

Assuming that .match, .filter, and .forEach are actually curried non-method curried unary functions, then—as I mentioned in #202—I am planning to pursue a proposal for a standard Function.pipe function at TC39. With that, one would write this:

Function.pipe(stream,
  match({ topic: 'available' }),
  filter(status => ['started', 'exited'].includes(status.type)),
  forEach(function*(status) {
    yield send(status);
  }),
});

Would that satisfy your use case?

Of course I forgot about types entirely when I gave my answer, so no, this would not really satisfy the use-case. It would work ok for JavaScript users, but the entire reason we're using chaining in the first place is to preserve type context for TypeScript users.

@js-choi js-choi added the question Further information is requested label Mar 15, 2022
@js-choi
Copy link
Collaborator

js-choi commented Mar 15, 2022

Of course I forgot about types entirely when I gave my answer, so no, this would not really satisfy the use-case. It would work ok for JavaScript users, but the entire reason we're using chaining in the first place is to preserve type context for TypeScript users.

Thanks for your comment. I’m a little confused by this, though, sorry. The pipe functions in RxJS and Ramda already work with TypeScript type inference (albeit with some limitations: they have to declare type signatures for their nullary, unary, binary, ternary, etc. arity overloads).

The Function.pipe function would merely be a standardized version of the RxJS and Ramda functions in the language core, and it would easily be annotated with TypeScript types in the same way as the RxJS and Ramda versions.

See also #219.

@cowboyd
Copy link
Author

cowboyd commented Mar 15, 2022

Ah, I see. I was not aware of the Rx and Rambda method of "war-typing" but I guess that works 👍🏻

@cowboyd cowboyd closed this as completed Mar 15, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants