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 |
0 replies
|
This was included in the |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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,
Provideronly 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.Handlerat top level. This effectively rename Handler -> Provider, so is a significant change to the terminology used in the project.By suggesting that the
handler-explicitis 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.$namewould becomeProvider.$namein the user land.I'd like to think a bit more about this, and would be interested by third-parties opinions on this subject.
All reactions