Open
Description
While writing an example that uses hooks, I noticed that they were very hard to use correctly, and reasonable-looking code would silently ignore the request type you think you're hooking into.
We should provide {add,remove}Hook{,_}
variants which are specialised to each hook type and are harder to misuse:
addHookFor
andaddHookFor_
should be moved to the bottom of the file and marked{-# DEPRECATED #-}
with a message recommending the hook-specific functions, and promising removal in 2.2. The export list forAmazonka.Env.Hooks
should have a-- * section
for deprecated functions.addAWSRequestHook
should be renamed toaddRequestHookFor
, andaddAWSRequestHook
should remain as a{-# DEPRECATED #-}
alias, also scheduled for removal in 2.2.addAWSRequestHook_
should be deprecated and scheduled for removal in 2.2.removeHooksFor
andremoveHooksFor_
should be moved to the bottom of the file and deprecated, much the same as №1.- For each field in the
Hooks
record (examplerequestRetry
) that has aforall a
, we should have:- An add-for function for this hook:
addRequestRetryHookFor :: forall a b. Hook_ (Request a, Text, Retry.RetryStatus) -> Hook_ (Request b, Text, Retry.RetryStatus) -> Hook_ (Request b, Text, Retry.RetryStatus) = addHookFor_ @(Request a, Text, Retry.RetryStatus)
- A remove-for function for this hook:
removeRequestRetryHookFor :: _ = removeHookFor_
- An add-for function for this hook:
- Haddocks for each new function from №5
- Export these in a new
-- ** Functions for specific hooks
first, with an explanatory note:-- ** Functions for specific hooks -- $functions-specific-hooks (say that the type application for these is the AWS Request type e.g. `@S3.GetObject`.) addRequestHookFor, removeRequestsHooksFor, ... -- ** Functions for arbitrary hooks -- $functions-arbitrary-hooks noHook, noHook_, addHook, addHook_, ...