Split class definition among several files

Is there a way in Scala to split a class definition among several (in my case two) files?
I want to provide my students with a partially implemented class, and ask them to finish the implementation by implementing certain methods. Do I have to give them the source code for the class in editable form?

1 Like

You can give them a partial implementation in a trait they can mix in.

Isn’t basic inheritance enough? Abstract super class with abstract methods would suffice, I think. Then ask students to make non-abstract subclass.

Trait mixing is also an option, but is it needed here?

So here is the class hierarchy

abstract class Bdd (...) { ...}
abstract class BddTerm(...) {...}
object BddTrue extends BddTerm(...) {...}
object BddFalse extends BddTerm(...){...}
case class BddNode(...) extends Bdd(...){...}
object Bdd { ... }

Given that existing hierarchy including unit tests for the behavior, how do you propose students effectively add requested features. Some of the behavior makes sense to implement in the Bdd object; other is most natural to implement in the Bdd class, perhaps in BddNode. If students are intended to implement their own class, then doesn’t my BddNode class need to a priori know about it and extend it? Otherwise the test cases won’t be aware of the code the students write. Right?

It seems to me that putting a bunch of empty abstract classes in place to allow the code from the lecture compile, and asking students to re-implement and make sure the compiler sees their implementation and not the empty one from the lecture, seems like making a simple problem very confusing.

Maybe I’m missing something. I’m sure I am, because I’m really at the lowest level, thinking in terms of the behavior I want, and trying to translate this into the language and concepts/strengths/limitations of Scala.

I’m short on time right now, but if abstract classes are too cumbersome then you can always throw exception in a method indicating that it should be implemented, e.g:

class Abc {
  def method(a: String, b: Int, c: Char): List[Int] =
    throw new Exception("implement this method")
}

Scala has even built-in method that throws exception, it’s Predef.??? so you can write:

class Abc {
  def method(a: String, b: Int, c: Char): List[Int] = ??? // TODO: implement this method
}

This way the program will compile fine, but fail at runtime until it’s implemented.

That’s what I’m planning on doing to use the ???.

Currently though my unit tests abort the first time it reaches one of them, rather than simply marking the test as failing. :frowning: I’m pretty sure there’s a way to fix that. it’s on my todo list.

BTW Piotr, thanks for all your help.

No problem :slight_smile:

??? throws an Error, not an Exception: https://www.scala-lang.org/api/current/scala/NotImplementedError.html so this is regarded as fatal by this thing: https://www.scala-lang.org/api/current/scala/util/control/NonFatal$.html and NonFatal is used in many places.

You can define your own method which throws a subclass of Exception, e.g.:
def TODO(message: String): Nothing = throw new UnsupportedOperationException(message)
and use it in your classes.

1 Like

Agreed with the above that ??? (or equivalent) are your friend here – I often do that for class materials.

Also, you might want to note the “should not compile” mechanism in ScalaTest, which is sometimes really handy for this sort of situation. My problem sets are generally written as ScalaTest tests, and pretty often I will wrap the actual test in a shouldNot compile clause. The task of the student is to implement whatever is missing, then remove the shouldNot compile wrapper to confirm that it does now compile and run…

1 Like