1

When we do Some(“some values”).size it returns 1. When we do None.size it returns 0. I was wondering what could be the possible use of the size method on an option. 

val x = Some(1,2,3,4).size
println(x) // prints 1
val y = Some(List(“a”, ”b”, ”c”, ”d”))
println(y) //it also print 1

When we are going to have 1 for any kind of value inside Some and 0 for None. What is the use of this size method over Option.

One possible use I can think of is to know whether the option is defined in case of (Some) and size is 1 or not when None and size is 0.

But is doesn’t make sense because we already have isDefined to check that.

Xavier Guihot
  • 54,987
  • 21
  • 291
  • 190
Raman Mishra
  • 2,635
  • 2
  • 15
  • 32
  • 2
    Wouldn't this be for consistency with the various monadic collections? – Don Branson May 17 '18 at 16:13
  • Consider `toArray` or something - it's simply useful to know the number of elements – Bergi May 17 '18 at 16:14
  • It’s just because of consistency? I don’t think so. – Raman Mishra May 17 '18 at 16:15
  • @Bergi toArray.size we already have then why we should have it on option? – Raman Mishra May 17 '18 at 16:16
  • @RamanMishra I mean in the implementation of `toArray`, where we need to know the size of the array to allocate before filling it – Bergi May 17 '18 at 16:18
  • Why you are talking about the toArray can you please explain it in the answer I am not getting your point. I am talking about monads which implement two methods unit and the flatMap. Monads are wrapper for the object. – Raman Mishra May 17 '18 at 16:29
  • 4
    It doesn't have much to do with monads. There are many monads where a `size` method wouldn't make any sense. There are also many monads for which `permutations` wouldn't make any sense. The `Option` has a `size` method because it's something like a collection with at most one element, not because it's a monad. – Andrey Tyukin May 17 '18 at 16:48

2 Answers2

5

The size method does not have anything to do with the fact that Option is also a monad. The concept of a monad is quite general, it applies to a lot of things, and all those things will typically have many more methods that just unit and flatMap. Option has a size method because it is implicitly convertible via Option.option2iterable into an Iterable. This makes sense, because an Option is a collection with at most one element.

I don't see any reason why isDefined should "make more sense" than size. None of those methods are strictly necessary. In fact, all methods on Option could be expressed in terms of fold only. For example, isDefined could be defined as

def isDefined = fold(false){ _ => true }

Likewise, size could also be defined through a fold:

def size = fold(0){ _ => 1 }

Does it now mean that we should throw away all methods except fold? No, not at all. "Rich interfaces" implemented as traits that provided tons of derived methods were probably the main reason why Scala's collections are so much more pleasant to use compared to, for example, Java's collections. By now, the difference has become smaller, because Java has also introduced default method implementations that do something similar, but this just shows once again that rich interfaces are inherently useful.

Andrey Tyukin
  • 43,673
  • 4
  • 57
  • 93
3

The size method is added because Options are implicitly converted to an Iterable. Iterable provides a ton of useful methods without having to be specifically reimplemented for Options. By reusing that code, Options gain consistency with all other containers, and are much more reusable themselves.

In other words, it lets you pass an Option into a function expecting an Iterable, where that function only knows about methods like size and not Option-specific methods like isDefined.

Really, isDefined is the method you don't strictly need, because it only makes sense for the narrow Option type. It's just there to provide a semantically nicer name than size or isEmpty.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94