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
Use classes to access context #690
Conversation
I don't mind the proposal, but I don't also see any huge gain. This is hardly the sort of access pattern that really requires sophisticated record libs (you just construct the datatype once, and never again modify it) (Presumably we don't want to actually depend on |
The gain: it's much more approachable (especially if we don't use lens, but only getter functions) to people who aren't comfortable with At work I construct The TL;DR it's hard to balance between "simplicity of implementation" and "not much boilerplate", but for that reason |
Hmm, interesting. On the one hand I think configuring handlers and combinators are distinct enough to be kept as separate notions, but on the other I do see how it'd be useful if the same datatype could be used for both so that one ends up with a single configuration datatype. I'm overall coming over to this idea, but still have a question. Let's say we have a default config - the one one |
@jkarni: we could still provide hlist- So it would be better to have only getters, as then |
I'll improve this after 0.10 is out. Showing code will probably help. |
I have a few ideas in that space I'd like us to experiment with, so I agree that we should postpone this to after 0.10. |
As an example what I mean in #689: We don't need to force which construct is used as
context
. Users should be free to pick their own "extensible-records" library (if they want to use one).