scala: how to view subclass methods with a generic instantiation

Question

I have the following where I set information and extractors for different schemes of data:

trait DataScheme {
    type Type <: List[Any]
    class ExtractorMethods(ticker: String, dataList: List[Type]) {
        def getDatetime(datum: Type): Date = new Date(datum(columnIndex(Names.datetime)).toString)
        def upperDatum(date: Date): Type = dataList.minBy(datum => getDatetime(datum) >= date)
        def lowerDatum(date: Date): Type = dataList.maxBy(datum => getDatetime(datum) <= date)
    }
}
trait IndexScheme extends DataScheme {
    type Type = (Date, Double, Double, Double, Double, Long)
    class ExtractorMethods(ticker: String, dataList: List[Type]) extends super.ExtractorMethods(ticker: String, dataList: List[Type]){
        def testing12(int: Int):Int = 12
        val test123 = 123
    }
}

I want anything extending DataScheme to use its ExtractorMethods methods (e.g. lowerDatum) but also have its own methods (e.g. testing12).

There is a class definition for lists of data elements:

class Data[+T <: DataScheme](val ticker: String, val dataList: List[T#Type], val isSorted: Boolean)
    (implicit m: Manifest[T], mm: Manifest[T#Type]) extends Symbols {
    def this(ticker: String, dataList: List[T#Type])(implicit m: Manifest[T], mm: Manifest[T#Type]) = this(ticker, dataList, false)(m: Manifest[T], mm: Manifest[T#Type])
    val dataScheme: T
    val extractorMethods = new dataScheme.ExtractorMethods(ticker, dataList.asInstanceOf[List[dataScheme.Type]])
}

A Data class should make accessible the methods in ExtractorMethods of the scheme so they can be used in the main program through the instance of Data that has been defined. For example if sortedData is an instance of Data[IndexScheme], the following works:

val lowerDatum = sortedData.extractorMethods.lowerDatum(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse("2010-03-31 00:00:00"))

but this does not:

val testing = sortedData.extractorMethods.testing12(123)

because 'testing 123 is not a member of sortedData.dataScheme.extractorMethods'. So my question is how can the subclasses of ExtractorMethods in the subtraits of DataScheme like IndexScheme be made accessible? How is it possible using Manifests and TypeTags? Thanks.

Answer 1

So you want the generic class Data[DataScheme] or Data[IndexScheme] to have access to the methods of whichever type Data has been parameterised with. You've tried to do this several different ways, from the evidence in your code.

To answer your last question - manifests can't help in this particular case and TypeTags are only part of the answer. If you really want to do this, you do it with mirrors.

However, you will have to make some changes to your code. Scala only has instance methods; there are no such things as static methods in Scala. This means that you can only use reflection to invoke a method on an instance of a class, trait or object. Your traits are abstract and can't be instantiated.

I can't really tell you how to clean up your code, because what you have pasted up here is a bit of a mess and is full of different things you have tried. What I can show you is how to do it with a simpler set of classes:

import scala.reflect.runtime.universe._

class t1 {
  class Methods {
    def a = "a"
    def b = "b"
  }
  def methods = new Methods
}

class t2 extends t1 {
  class Methods extends super.Methods {
    def one = 1
    def two = 2
  }
  override def methods = new Methods
}

class c[+T <: t1](implicit tag: TypeTag[T]) {

  def generateT = {
    val mirror = runtimeMirror(getClass.getClassLoader)
    val cMirror = mirror.reflectClass(typeOf[T].typeSymbol.asClass)
    cMirror.reflectConstructor(typeOf[T].declaration(nme.CONSTRUCTOR).asMethod)
  }
  val t = generateT().asInstanceOf[T]
}

val v1 = new c[t1]
val v2 = new c[t2]

If you run that, you'll find that v1.t.methods gives you a class with only methods a and b, but v2.t.methods gives a class with methods one and two as well.

This really is not how to do this - reaching for reflection for this kind of job shows a very broken model. But I guess that's your business.

I stick by what I said below, though. You should be using implicit conversions (and possibly implicit parameters) with companion objects. Use Scala's type system the way it's designed - you are fighting it all the way.

ORIGINAL ANSWER

Well, I'm going to start by saying that I would never do things the way you are doing this; it seems horribly over-complicated. But you can do what you want to do, roughly the way you are doing it, by

1. Using mixins
2. Moving the extractorMethods creation code into the traits.

Here's a greatly simplified example:

trait t1 {
  class Methods {
    def a = "a"
    def b = "b"
  }
  def methods = new Methods
}

trait t2 extends t1 {
  class Methods extends super.Methods {
    def one = 1
    def two = 2
  }
  override def methods = new Methods
}

class c1 extends t1 
val v1 = new c1
// v1.methods.a will return "a", but v1.methods.one does not exist
class c2 extends c1 with t2
val v2 = new c2
// v2.methods.a returns "a" and v2.methods.one returns 1

I could replicate your modus operandi more closely by defining c1 like this:

class c1 extends t1 {
  val myMethods = methods
}

in which case v1.myMethods would only have methods a and b but v2.myMethods would have a, b, one and two.

You should be able to see how you can adapt this to your own class and trait structure. I know my example doesn't have any of your complex type logic in it, but you know better than I what you are trying to achieve there. I'm just trying to demonstrate a simple mechanism.

But dude, way to make your life difficult...

EDIT

There are so many things I could say about what is wrong with your approach here, both on the small and large scale. I'm going to restrict myself to saying two things:

1. You can't do what you are trying to do in the Data class because it is abstract. You cannot force Scala to magically replace an uninitialised, abstract method of a non-specific type with the specific type, just by littering everything with Type annotations. You can only solve this with a concrete class which provides the specific type.

2. You should be doing this with implicit conversions. Implicits would help you do it the wrong way you seem fixated on, but would also help you do it the right way. Oh, and use a companion object, either for the implicits or to hold a factory (or bot).