You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to drop the method-based API for several reasons:
One way is better than two (for users primarily; implementation simplicity secondarily).
$ python -c 'import this'| grep 'only one'There should be one-- and preferably only one --obvious way to do it.
this is an implicit argument. Explicit is better than implicit.
$ python -c 'import this'| grep 'implicit'Explicit is better than implicit.
The function-based API supports partial application and thus works well with Ramda-style functional pipelines; the method-based API does not.
Sanctuary favours functions (for the reasons listed above). It provides a fromMaybe function, for example, rather than a getOrElse method.
How do you feel about this proposal, @JAForbes? I realize I'm pulling the project further from your goal of maintaining backwards compatibility with union-type, but union-type embraces JavaScript's dynamic nature whereas Sanctuary projects do not. Optional arguments, ad hoc polymorphism, and this are used heavily in union-type, but are at odds with the Sanctuary philosophy.
The text was updated successfully, but these errors were encountered:
I agree. Pending your decision on #6 I think dropping all instance methods is a great idea.
I think it might be worth considering the proposal I made in #6 as well about having a single case function that acts as a pattern matching operator. But I'm not wed to any particular implementation as long as I have a backwards compatible version living somewhere.
Function-based API:
Method-based API:
I would like to drop the method-based API for several reasons:
One way is better than two (for users primarily; implementation simplicity secondarily).
this
is an implicit argument. Explicit is better than implicit.The function-based API supports partial application and thus works well with Ramda-style functional pipelines; the method-based API does not.
Sanctuary favours functions (for the reasons listed above). It provides a
fromMaybe
function, for example, rather than agetOrElse
method.How do you feel about this proposal, @JAForbes? I realize I'm pulling the project further from your goal of maintaining backwards compatibility with union-type, but union-type embraces JavaScript's dynamic nature whereas Sanctuary projects do not. Optional arguments, ad hoc polymorphism, and
this
are used heavily in union-type, but are at odds with the Sanctuary philosophy.The text was updated successfully, but these errors were encountered: