3 ms·
While I have some appreciation for the fact that Scala doesn't make its `Option` type special from a syntactic standpoint--it's a sum type, like any other--I th
by acjohnson55 12y ago
While I have some appreciation for the fact that Scala doesn't make its `Option` type special from a syntactic standpoint--it's a sum type, like any other--I think there's something to be said for the type union with syntactic support. `optionalData?.methodOption?.method` is much more succinct than Scala's `optionalData.flatMap(_.methodOption).map(_.method)`, or `for (data <- optionalData; result <- data.methodOption) yield result.method`. Scalaz seems to provide some more concise aliases for the monadic chain, but there's still nothing I know of that gives you exactly the method access within a monad quite like `?.`.
- justthistime_ 12y agoScala encourages people to not use nulls everywhere, so adding syntactic sugar for a special case, which is not even idiomatic Scala doesn't sound like a good idea. Option is not a "replacement" for null. Sometimes another type is more appropriate to replace a usage of a null in Java/C#, so making Option special would be counter-productive.
- acjohnson55 12y agoI wouldn't use null anywhere in my Scala code, unless I had to in order to interface with a Java library. I'm talking about sugar for working with Option.
- justthistime_ 12y agoWhere would this sugar stop? At Either? At Try? At Validation? The problem is that if you introduce the sugar only for Option, users will tend to use Option even in cases where other type constructors would be more appropriate.