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

Functional Hook APIs #37

Open
sugarmanz opened this issue Mar 26, 2024 · 2 comments
Open

Functional Hook APIs #37

sugarmanz opened this issue Mar 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@sugarmanz
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

When tapping a hook that provides an abstract data type, we may only care about a specific implementation. A simple early return allows us to "filter" out types we don't care about:

interface Super

class A : Super
class B : Super

val hook: SyncHook<(Super) -> Unit>
hook.tap(name) { super ->
    if (super !is A) return@tap

    // ...
}

Describe the solution you'd like

It'd be awesome to have functional methods for hooks, such that we can patternize filtering, data manipulation, etc.

hook.filterIsInstance<A>().tap(name) { a ->
    // ...
}

Describe alternatives you've considered

Tapping can effectively be thought of as collecting. Maybe it's worth adopting similar terminology? Probably not. Maybe a conversion layer to Flows would solve better than trying to coerce hooks as a Flow-like data type.

Additional context

This is somewhat difficult to consider for the more complex hook types, since return value is more important. We'd want to ensure we have appropriate handling for each hook type, or not support certain hook types at all.

@sugarmanz sugarmanz added the enhancement New feature or request label Mar 26, 2024
@brocollie08
Copy link
Contributor

re. return value, you can still support all hook types but at the call site, only process the taps that qualify?

Also would you consider something like tapIsInstance?

@sugarmanz
Copy link
Collaborator Author

only process the taps that qualify?

Conceptually, yes - but we'd need to tap to process the hook value for filter or map or w/e. So, for instance, if I try to filter on waterfall hook value, if it doesn't match the filter, I'd need to return the incoming value from the filter method.

tapIsInstance

I don't really see why not, but the idea is to mirror collection or flow-like APIs that already exist. Collapsing a few into a singular tap convenience would definitely be in scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants