Scala generics Confusion

Question

I have some generic/OOP Scala code (not useful, just classroom excercises)

I have a Container interface, "IterableContainer", that takes in and returns objects whose type is a subclass of AnyRef. It has a concrete sub-class that also takes in and returns objects whose type is a subclass of AnyRef.

  trait IterableContainer[Type <: AnyRef] {

    def length: Int

    def getAt(index: Int): Type

    def append(element: Type)
  }

  class IterableArrayList[T <: AnyRef]() extends IterableContainer[T] {

    val underlyingContainer = new ArrayBuffer[T](16)

    override def length: Int = {
      return underlyingContainer.length
    }

    override def getAt(index: Int): T =
    {
      if (index < underlyingContainer.length) {
        return underlyingContainer(index)
      } else {
        return null // Expression of type T does not conform to expected type. 
      }
    }

    override def append(element: T) = {
      underlyingContainer :+ element // :+ means append
    }
  }

Can anyone explain why I cannot return null when T is explicitly being stated as a an object of a type that extends AnyRef?

Also, if you understand Scala's generics better than I do, please explain further - they really make no sense to me (relative to C++ generics).

Just FYI, your use of `return` isn't very idiomatic. You can actually delete all the `return`s from your code, and it would still work (and it would be considered "better style"). — DaoWen, Oct 10 '15 at 00:56
Also, your `append` method currently has return-type `Unit`... Probably not what you want. — DaoWen, Oct 10 '15 at 03:21
I didn't intend for the append method to return anything - just append something and return void (Unit). Also, when I did ":+" for append, it didn't actually append anything - the length of the ArrayBuffer stayed at zero. — Michael Lafayette, Oct 10 '15 at 03:33
Ah, that makes sense then. You should try using `+=` instead of `:+`. (`:+` returns a new collection rather than mutating the original.) — DaoWen, Oct 10 '15 at 03:47

DaoWen · Accepted Answer · 2015-10-10T03:16:40.430

The problem is that T <: AnyRef does not imply that T >: Null.

I believe the only counter-example is Nothing.

Adding an additional (lower) type bound on your IterableArrayList's type parameter makes the compiler happy:

class IterableArrayList[T >: Null <: AnyRef]() extends IterableContainer[T] {

Now the compiler knows that T is a subtype of AnyRef and a supertype of Null.

Now, you may be thinking to yourself, "Doesn't this cause all sorts of problems for writing library code in Scala? People must have to add T >: Null everywhere!"

However, the answer is no.

Why? Because Scala programmers pretty much never use null.

Let's look at List as an example. There are two ways to get the first element of a list:

def head: A (scaladoc)

def headOption: Option[A] (scaladoc)

If you call head on an empty list, you get an exception. If you call headOption on an empty list, then you get None.

That's the usual strategy for Scala libraries: either you throw an exception, or you return an Option type—you never return null.

Example using Option[T]:

override def getAt(index: Int): Option[T] =
  if (index < underlyingContainer.length) {
    Some(underlyingContainer(index))
  } else {
    None
  }

Example using an exception:

override def getAt(index: Int): T = underlyingContainer(index)

Note that the underlying ArrayBuffer already throws an IndexOutOfBoundsException if the index is invalid. This also has the added advantage of working correctly if the user passes in a negative index... (You might want to add a 0 <= index to your condition if you go with using Option.)

So I would either return Some[T] or None? – Michael Lafayette Oct 10 '15 at 01:55 — Michael Lafayette, Oct 10 '15 at 01:55
@MichaelLafayette - Yes, see the examples I added. – DaoWen Oct 10 '15 at 03:11 — DaoWen, Oct 10 '15 at 03:11

Scala generics Confusion

1 Answers1