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.

Sign up for GitHub

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

Jump to bottom

Consider using parameters rather than receivers for lambdas #47

Closed
robfletcher opened this issue Jun 5, 2018 · 0 comments
Closed

Consider using parameters rather than receivers for lambdas #47

robfletcher opened this issue Jun 5, 2018 · 0 comments
Labels
💥 breaking change Will change APIs in a non-backward compatible way 🤔 question Further information is requested
Projects
Release 1.0
Milestone
v1.0

Comments

@robfletcher
Copy link
Owner

Reasons this may be desirable:

  1. Receivers are neat but not necessarily as readable.
  2. Name conflicts are not handled very well if a variable in the test has the same name as a field in e.g. AssertionContext.
@robfletcher robfletcher added 🤔 question Further information is requested 💥 breaking change Will change APIs in a non-backward compatible way labels Jun 5, 2018
@robfletcher robfletcher added this to the v1.0 milestone Jun 5, 2018
@robfletcher robfletcher added this to To do in Release 1.0 Jul 20, 2018
Release 1.0 automation moved this from To do to Done Aug 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
💥 breaking change Will change APIs in a non-backward compatible way 🤔 question Further information is requested
Projects
Release 1.0
  
Done
Milestone
v1.0
Development

No branches or pull requests
1 participant
@robfletcher