Replies: 2 comments
-
I made the changes discussed here in #35. After going over the changes and upgrading user code, I find this new api more ergonomic and simpler. Consequently I will plan on merging this in. This will be shipped with the other change to making Trait via functors (#34), so effectively we'll have a new release |
Beta Was this translation helpful? Give feedback.
0 replies
-
This was included in the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Recently I worked on a tutorial demonstrating a pattern where functions take both a handler and a value, non bundled together.
This got me thinking a bit about whether this workflow would not be better off be promoted as the preferred style, over bundling the handler with an internal state. Presumably, when we do bundle, the internal state is likely mutable, so effectively we are currently favoring a non-functional style. This shouldn't come as a total surprise, given that the library started as a pattern to replicate the behavior of objects.
Currently,
Provider
only exposes one single type at top level:The entire API is in
Provider.Handler
.What I am saying here, is that perhaps it would be preferable to rename the type to emphasis that it is about bundling (or packing) bindings with a state, and make room to promote the
Provider.Handler
at top level. This effectively rename Handler -> Provider, so is a significant change to the terminology used in the project.By suggesting that the
handler-explicit
is the preferred style, we would re-enforce the parallel that can be drawn between provider and modular-explicit. This would also make the interface less verbose : all calls toProvider.Handler.$name
would becomeProvider.$name
in the user land.I'd like to think a bit more about this, and would be interested by third-parties opinions on this subject.
Beta Was this translation helpful? Give feedback.
All reactions