Skip to content

add better EventLoopPreference names #243

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

Open
weissi opened this issue Jun 13, 2020 · 1 comment
Open

add better EventLoopPreference names #243

weissi opened this issue Jun 13, 2020 · 1 comment
Labels
kind/enhancement Improvements to existing feature.
Milestone

Comments

@weissi
Copy link
Contributor

weissi commented Jun 13, 2020

Right now, we have three (public) EventLoopPreferences:

  1. .delegate(on: EventLoop)
  2. .indifferent
  3. .delegateAndChannel(on: EventLoop)

I did propose this naming personally so I feel a little sheepish for proposing to change (or just add better) names. But let me explain how we got here:

When I proposed this, I thought that the user only wants to choose the EL for the delegate callouts. To use AHC however, a user needs more guarantees. Almost all users will want to specify an EL and they require the following things to happen the specified EL:

  • Task.futureResult needs to be bound to the specified EL
  • all delegate methods need to be called on the specified EL
  • all other callouts need to be called on the specified EL

Today (and in the future), .delegate(on: el) does exactly that. The naming however is confusing because it only mentions the delegate (but not the future or other callouts).

My new proposed naming is:

  1. .on(EventLoop)
  2. .indifferent
  3. .forceChannelAndCalouts(on: EventLoop)

Maybe to reduce the number of deprecation warnings we should do

  1. .on(EventLoop)
  2. .delegate(on: EventLoop) (same as .on(EL))
  3. .indifferent
  4. . forceChannelAndCalouts(on: EventLoop)
  5. .delegateAndChannel(on: EventLoop) (same as . forceChannelAndCalouts(on: EL))

I think we need to focus on the 99% case and the 99% case is that users really don't care where the Channel lives but they very much care where the future and all the callouts come from.

That means that we mostly need to focus on the name of the 99% case and I think eventLoopPreference: .on(myEL) is great.

All the other cases (2 - 5) are really for special uses so it's actually good if the names are slightly longer.

@weissi
Copy link
Contributor Author

weissi commented Jun 13, 2020

(the existing naming came in #102 with the discussion happening mostly in #100 )

@artemredkin artemredkin added the kind/enhancement Improvements to existing feature. label Jun 13, 2020
@artemredkin artemredkin added this to the 2.0.0 milestone Jun 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements to existing feature.
Projects
None yet
Development

No branches or pull requests

3 participants