[x] Just.IsJust(), Nothing.IsNothing(), corresponding IMaybe props -> property, not method
[x] MapOr -> SelectOr
[x] MapOrElse -> SelectOrElse
Notes
As noted, the Just.IsJust() and Nothing.IsNothing() methods should be simple properties, not methods. (The reason they were methods in the TS implementation was so they could be used for "type narrowing.") I would keep the Maybe.IsJust() and Maybe.IsNothing() static methods which are useful for checking them in a "functional" style.
We probably don't need any of the aliases from the original implementation, because they are just there for ease of migration from other JS libraries.
ap is named ap instead of apply only because apply already has a usual meaning in JS. I don't think that's the case here, so using Apply makes way more sense to me.
On curried methods
It's certainly not difficult to supply overloads of the functions for a "functional" style—but it's also not especially idiomatic in C♯ from everything I've seen, so the value proposition seems lower. If folks want it, my thought is we can add them in e.g. a 1.1 release—but I'm happy to help get them shipped if it turns out people do really want them!
aggieben
commented
5 years ago
Here's the reference implementation in TypeScript.
Functions and methods to implement:
Maybestatic methodsap(probably makes sense to name itApply)equalsmatchtoStringJustandNothingmethodsap(probably makes sense to name itApply)equalsmatchtoStringJust.IsJust(),Nothing.IsNothing(), correspondingIMaybeprops -> property, not methodMapOr->SelectOrMapOrElse->SelectOrElseNotes
Just.IsJust()andNothing.IsNothing()methods should be simple properties, not methods. (The reason they were methods in the TS implementation was so they could be used for "type narrowing.") I would keep theMaybe.IsJust()andMaybe.IsNothing()static methods which are useful for checking them in a "functional" style.apis namedapinstead ofapplyonly becauseapplyalready has a usual meaning in JS. I don't think that's the case here, so usingApplymakes way more sense to me.On curried methods
It's certainly not difficult to supply overloads of the functions for a "functional" style—but it's also not especially idiomatic in C♯ from everything I've seen, so the value proposition seems lower. If folks want it, my thought is we can add them in e.g. a 1.1 release—but I'm happy to help get them shipped if it turns out people do really want them!