Yet another solution is to specify a default type for the parameter as follows:
object Finder {
def find[T <: Node](name: String)(implicit e: T DefaultsTo Node): T =
doFind(name).asInstanceOf[T]
}
The key is to define the following phantom type to act as a witness for the default:
sealed class DefaultsTo[A, B]
trait LowPriorityDefaultsTo {
implicit def overrideDefault[A,B] = new DefaultsTo[A,B]
}
object DefaultsTo extends LowPriorityDefaultsTo {
implicit def default[B] = new DefaultsTo[B, B]
}
The advantage of this approach is that it avoids the error altogether (at both run-time and compile-time). If the caller does not specify the type parameter, it defaults to Node
.
Explanation:
The signature of the find
method ensures that it can only be called if the caller can supply an object of type DefaultsTo[T, Node]
. Of course, the default
and overrideDefault
methods make it easy to create such an object for any type T
. Since these methods are implicit, the compiler automatically handles the business of calling one of them and passing the result into find
.
But how does the compiler know which method to call? It uses its type inference and implicit resolution rules to determine the appropriate method. There are three cases to consider:
find
is called with no type parameter. In this case, type T
must be inferred. Searching for an implicit method that can provide an object of type DefaultsTo[T, Node]
, the compiler finds default
and overrideDefault
. default
is chosen since it has priority (because it's defined in a proper subclass of the trait that defines overrideDefault
). As a result, T
must be bound to Node
.
find
is called with a non-Node
type parameter (e.g., find[MyObj]("name")
). In this case, an object of type DefaultsTo[MyObj, Node]
must be supplied. Only the overrideDefault
method can supply it, so the compiler inserts the appropriate call.
find
is called with Node
as the type parameter. Again, either method is applicable, but default
wins due to its higher priority.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…