The new Apply spec
See original GitHub issueDid I take Crazy Pills?
More of a question than an actual issue. I think I may be missing something with the new Apply spec updated a wee bit ago. So I started to make updates to my project to reflect this change and it seems to me like this change is limiting the API. Just want to make sure I have this right. So an Identity used to be:
function Identity(x) {
const map = fn => Identity(fn(x))
const value = R.always(x)
const ap = m => m.map(x)
return { map, value, ap }
}
and I could “chain” it outside of a lift function as:
// data === Identity 8
const data =
Identity(add)
.ap(Identity(3))
.ap(Identity(5))
// or
// data === Identity 8
const another =
Identity(3)
.map(add)
.ap(Identity(5))
Never have to extract in the container and I have the option of having one of the parameters do the lifting for me through map
, if I choose to.
But if I am reading the spec correct it means it all looks and feels like this now:
function Identity(x) {
...
const ap = m => Identity(m.value()(x))
...
}
const data =
Identity(4)
.ap(
Identity(5)
.ap(Identity(add))
)
Now am I missing how to use this? It seem like I lose the ability to “chain” and am always stuck with this composing interface. So if I am reading that right it seems that we lose the ability to choose how our flows are constructed and either have to provide our users lift functions to hide all of this away from them, or limit them to this interface.
Now I am very new at this, so I am probably missing something really cool and clever here. But I guess I have two questions:
- What is the value of making this change? (or why was it wrong to begin with)
- Is there a better way to use this outside of writing liftAN functions.
Issue Analytics
- State:
- Created 7 years ago
- Comments:8 (8 by maintainers)
Top GitHub Comments
Consistency.
Before:
After:
There you go 👍