Closed lvicentesanchez closed 9 years ago
Does scala.Option
have any obvious deficiencies like scala.Either
?
The most obvious to me is the get
method that can raise an Exception if your Option variable contains a None.
get
method.None
as null
at runtime, and hence disallows Some(null)
.Not convinced this belongs in cats though.
Agreed. The value class idea is nice, but it isn't really an Option[_]
replacement since it can't represent Option[Option[_]]
.
There's also the implicit conversion to Iterable
, which can be a source of suffering. The zip
method is particularly fantastic.
So I think Maybe
would be nice to have, but in practice I think Scala developers learn what to avoid with Option
and don't get tripped up very often. I do lean toward including these things in cats eventually, but I am in the minority and won't argue loudly. For now I certainly agree that finishing up the core typeclasses and clearly missing/broken data types should be the priority.
I'm wary of trading the network effects of stdlib for these modest improvements. I would still rather cats.data
is for complementing stdlib and some other place for replacing it. (See also: collections.)
I'm OK with things like IList
and Maybe
existing and often time I will reach for them (quickly) for my own projects, but when working with existing code (e.g. at $JOB) where everyone else is using List
and Option
I'd still like to use cats
without having to deal with stdlib types and cats equivalent. I suppose what this boils down to is for outside-facing things, say some stream iteration function, I'd rather see B => Option[(A, B)] => Stream[A]
as opposed to B => Maybe[(A, B)] => Stream[A]
.
That being said I happily reach for Or
as an exception to this rule since the stdlib Either
is....... weird.
I agree that adding Maybe
as a replacement for Option
has less value than adding Or
as replacement for Either and I totally agree that this should not go to cats.data
.
My gut feeling is that this stuff belongs in a separate project.
Throwing my own opinion in here, which pretty much echoes most people here
I feel very little benefit in cats having a Maybe
type. Just because Option
happens to have a single unsafe method, and that its an Iterable
are very weak reasons. The boxing is a more legitimate concern, however something like miniboxing
is the right approach there.
I think one of the things to learn from Scalaz
is to not overbuild the entire stdlib just because everything isn't 100% "pure". Scalaz
also had a Maybe
type, which practically no one used. Then there is even worse stuff like IList
, which had severe performance characteristics in some situations (this is probably due to the fact that it wasn't as battle tested as stdlibs List
)
If people wan't to add Maybe
as another module, I am fine with that, however I think we need to be generally careful in not unnecessarily fragmenting the experience of users, which means keeping the core as clean and as small as possible (and I believe this is one of the design goals of cats)
It sounds like the decision is to stick with Option
. If someone really wants Maybe
, it could live in its own project. I'm going to go ahead and close this.
Also on the note regarding boxing (in response to @mpilquist), you can use name based extractors to avoid the boxing for Option
, i.e. check http://hseeberger.github.io/blog/2013/10/04/name-based-extractors-in-scala-2-dot-11/. I learnt this trick when writing a new JSON library
Should cats include the Maybe data type as an alternative to Option?