I understand what the result of a self type is as in
trait SpellChecker {
self: RandomAccessSeq[char] =>
...
}
from http://www.markthomas.info/blog/92
As far as I understand it says "the object instantiated from this trait is also of type RandomAccessSeq[char]". Is that right?
My question: What can I write after the => and what does it mean? I noticed I don't get a compiler error when writing AnyRef after the =>.
My question: What can I write after the =>
Anything.
and what does it mean?
It denotes the end of the self-type annotation. After that comes the normal trait body, just like as if the self-type annotation wasn't even there.
trait A { ta: B =>
// code
}
In this example ta is a this alias. It's useful as a shorthand for A.this, for when you need to reference this code from somewhere else.
Because ta (i.e. this code) is of type B, all of B's methods and member data are in scope and freely available. This becomes a contract that the compiler will enforce: because A code can reference B code, A cannot be instantiated without B also in the mix.
Related
Could some one please explain the generics involved in the following code from play framework
class AuthenticatedRequest[A, U](val user: U, request: Request[A]) extends WrappedRequest[A](request)
class AuthenticatedBuilder[U](userinfo: RequestHeader => Option[U],
onUnauthorized: RequestHeader => Result = _ => Unauthorized(views.html.defaultpages.unauthorized()))
extends ActionBuilder[({ type R[A] = AuthenticatedRequest[A, U] })#R]
The ActionBuilder actualy has type R[A], it is getting reassigned, this much I understand. please explain the intricacies of the syntax
The bit that's confusing you is called a "type lambda". If you search for "scala type lambda", you'll find lots of descriptions and explanations. See e.g. here, from which I'm drawing a lot of inspiration. (Thank you Bartosz Witkowski!)
To describe it very simply, you can think of it as a way to provide a default argument to a type constructor. I know, huh?
Let's break that down. If we have...
trait Unwrapper[A,W[_]] {
/* should throw an Exception if we cannot unwrap */
def unwrap( wrapped : W[A] ) : A
}
You could define an OptionUnwrapper easily enough:
class OptionUnwrapper[A] extends Unwrapper[A,Option] {
def unwrap( wrapped : Option[A] ) : A = wrapped.get
}
But what if we want to define an unwrapper for the very similar Either class, which takes two type parameters [A,B]. Either, like Option, is often used as a return value for things that might fail, but where you might want to retain information about the failure. By convention, "success" results in a Right object containing a B, while failure yields a Left object containing an A. Let's make an EitherUnwrapper, so we have an interface in common with Option to unwrap these sorts of failable results. (Potentially even useful!)
class EitherUnwrapper[A,B] extends Unwrapper[B,Either] { // unwrap to a successful result of type B
def unwrap( wrapped : Either[A,B] ) : B = wrapped match {
case Right( b ) => b // we ignore the left case, allowing a MatchError
}
}
This is conceptually fine, but it doesn't compile! Why not? Because the second parameter of Unwrapper was W[_], that is a type that accepts just one parameter. How can we "adapt" Either's type constructor to be a one parameter type? If we needed a version of an ordinary function or constructor with fewer arguments, we might supply default arguments. So that's exactly what we'll do.
class EitherUnwrapper[A,B] extends Unwrapper[B,({type L[C] = Either[A,C]})#L] {
def unwrap( wrapped : Either[A,B] ) : B = wrapped match {
case Right( b ) => b
}
}
The type alias part
type L[C] = Either[A,C]
adapts Either into a type that requires just one type parameter rather than two, by supplying A as a default first type parameter. But unfortunately, scala doesn't allow you to define type aliases just anywhere: they have to live in a class, trait, or object. But if you define the trait in an enclosing scope, you might not have access to the default value you need for type A! So, the trick is to define a throwaway inner class in a place where A is defined, just where you need the new type.
A set of curly braces can (depending on context) be interpreted as a type definition in scala, for a structural type. For instance in...
def destroy( rsrc : { def close() } ) = rsrc.close()
...the curly brace defines a structural type meaning any object with a close() function. Structural types can also include type aliases.
So { type L[C] = Either[A,C] } is just the type of any object that contains the type alias L[C]. To extract an inner type from an enclosing type -- rather than an enclosing instance -- in Scala, we have to use a type projection rather than a dot. The syntax for a type projection is EnclosingType#InnerType. So, we have { type L[C] = Either[A,C] }#L. For reasons that elude me, the Scala compiler gets confused by that, but if we put the type definition in parentheses, everything works, so we have ({ type L[C] = Either[A,C] })#L.
Which is pretty precisely analogous to ({ type R[A] = AuthenticatedRequest[A, U] })#R in your question. ActionBuilder needs to be parameterized with a type that takes one parameter. AuthenticatedRequest takes two parameters. To adapt AuthenticatedRequest into a type suitable for ActionBuilder, U is provided as a default parameter in the type lambda.
I have the following code:
sealed trait A
case class B[T](v: T) extends A
case class C[T](v: T) extends A
object Test {
def swap(a: A): A = a match {
case a: B[t] => C[t](a.v) // works!
case C[t](v) => B[t](v) // error: C[t] does not take parameters
}
}
I would expect either both cases to fail or both of them to work. What's the meaning of the error for the second case? Is there a syntax destructuring parametric case-classes?
Note: Here, 't' in lower case is essential. If it were 'T', the checker would be looking for it in the type parameters of the method.
When you do a match { case C(v) => ??? }, you actually call unapply method of the C companion object, something like this: C.unapply(a) match {Some(v) => ???}
There is only one C object, not an entire family of C[t]. There is no object you can refer to as C[Int], so case C[t](v) => doesn't make sense.
In your example, you use B[t] as a type, not as a pattern, and that's why it works. Note that while the match may succeed, you won't get anything in t, because of type erasure.
When you call C[t](a.v), then first of all, compiler erases type t anyway, and second, this is rewritten to a call to apply method on the companion object: C.apply[t](a.v). Note that the type parameter is on the method call, not on the object.
Simply put, it is not part of the language.
When used in this position, the compiler is looking for the type in the environment, as if it were a usual uppercase type. The type capturing that you are trying to do seems to only work in the case x:Y[z] => ... form of a case statement.
Type capturing in this fashion is not a well know part of the language and had me running to the Scala reference document for the details (Section 8.3). I personally find the that the distinction between upper and lowercase here not to my liking.
In your example t takes on the type of Any as the type information for the parameter is not available from A.
trait A { def someMethod = 1}
trait B { self : A => }
val refOfTypeB : B = new B with A
refOfTypeB.someMethod
The last line results in a type mismatch error. My question is: why it's impossible to reach the method (of A) when it's given that B is also of type A?
So B is not also of type A. The self type annotation that you've used here indicates specifically that B does not extend A but that instead, wherever B is mixed in, A must be mixed in at some point as well. Since you downcast refOfTypeB to a B instead of B with A you don't get access to any of type A's methods. Inside of the implementation of the B trait you can access A's methods since the compiler knows that you'll at some point have access to A in any implemented class. It might be easier to think about it as B depends on A instead of B is an A.
For a more thorough explanation see this answer: What is the difference between self-types and trait subclasses?
The problem is when you declare refOfTypeB, you have type B specified but not type B with A.
The self => syntax allow you to access the properties of A within B and pass the compilation.
However, in the runtime, refOfTypeB is not recognize as B with A and the compiler doesn't necessarily have the function map correctly.
So, the correct syntax should be:
trait A { def someMethod = 1}
trait B { self : A => }
val refOfTypeB : B with A = new B with A
refOfTypeB.someMethod //1
Indeed, this is more expressive in terms of explaining with what refOfTypeB exactly is.
This is the somehow the boilerplate of cake patterns.
I'm seeing something I do not understand. I have a hierarchy of (say) Vehicles, a corresponding hierarchy of VehicalReaders, and a VehicleReader object with apply methods:
abstract class VehicleReader[T <: Vehicle] {
...
object VehicleReader {
def apply[T <: Vehicle](vehicleId: Int): VehicleReader[T] = apply(vehicleType(vehicleId))
def apply[T <: Vehicle](vehicleType VehicleType): VehicleReader[T] = vehicleType match {
case VehicleType.Car => new CarReader().asInstanceOf[VehicleReader[T]]
...
Note that when you have more than one apply method, you must specify the return type. I have no issues when there is no need to specify the return type.
The cast (.asInstanceOf[VehicleReader[T]]) is the reason for the question - without it the result is compile errors like:
type mismatch;
found : CarReader
required: VehicleReader[T]
case VehicleType.Car => new CarReader()
^
Related questions:
Why cannot the compiler see a CarReader as a VehicleReader[T]?
What is the proper type parameter and return type to use in this situation?
I suspect the root cause here is that VehicleReader is invariant on its type parameter, but making it covariant does not change the result.
I feel like this should be rather simple (i.e., this is easy to accomplish in Java with wildcards).
The problem has a very simple cause and really doesn't have anything to do with variance. Consider even more simple example:
object Example {
def gimmeAListOf[T]: List[T] = List[Int](10)
}
This snippet captures the main idea of your code. But it is incorrect:
val list = Example.gimmeAListOf[String]
What will be the type of list? We asked gimmeAListOf method specifically for List[String], however, it always returns List[Int](10). Clearly, this is an error.
So, to put it in words, when the method has a signature like method[T]: Example[T] it really declares: "for any type T you give me I will return an instance of Example[T]". Such types are sometimes called 'universally quantified', or simply 'universal'.
However, this is not your case: your function returns specific instances of VehicleReader[T] depending on the value of its parameter, e.g. CarReader (which, I presume, extends VehicleReader[Car]). Suppose I wrote something like:
class House extends Vehicle
val reader = VehicleReader[House](VehicleType.Car)
val house: House = reader.read() // Assuming there is a method VehicleReader[T].read(): T
The compiler will happily compile this, but I will get ClassCastException when this code is executed.
There are two possible fixes for this situation available. First, you can use existential (or existentially quantified) type, which can be though as a more powerful version of Java wildcards:
def apply(vehicleType: VehicleType): VehicleReader[_] = ...
Signature for this function basically reads "you give me a VehicleType and I return to you an instance of VehicleReader for some type". You will have an object of type VehicleReader[_]; you cannot say anything about type of its parameter except that this type exists, that's why such types are called existential.
def apply(vehicleType: VehicleType): VehicleReader[T] forSome {type T} = ...
This is an equivalent definition and it is probably more clear from it why these types have such properties - T type is hidden inside parameter, so you don't know anything about it but that it does exist.
But due to this property of existentials you cannot really obtain any information about real type parameters. You cannot get, say, VehicleReader[Car] out of VehicleReader[_] except via direct cast with asInstanceOf, which is dangerous, unless you store a TypeTag/ClassTag for type parameter in VehicleReader and check it before the cast. This is sometimes (in fact, most of time) unwieldy.
That's where the second option comes to the rescue. There is a clear correspondence between VehicleType and VehicleReader[T] in your code, i.e. when you have specific instance of VehicleType you definitely know concrete T in VehicleReader[T] signature:
VehicleType.Car -> CarReader (<: VehicleReader[Car])
VehicleType.Truck -> TruckReader (<: VehicleReader[Truck])
and so on.
Because of this it makes sense to add type parameter to VehicleType. In this case your method will look like
def apply[T <: Vehicle](vehicleType: VehicleType[T]): VehicleReader[T] = ...
Now input type and output type are directly connected, and the user of this method will be forced to provide a correct instance of VehicleType[T] for that T he wants. This rules out the runtime error I have mentioned earlier.
You will still need asInstanceOf cast though. To avoid casting completely you will have to move VehicleReader instantiation code (e.g. yours new CarReader()) to VehicleType, because the only place where you know real value of VehicleType[T] type parameter is where instances of this type are constructed:
sealed trait VehicleType[T <: Vehicle] {
def newReader: VehicleReader[T]
}
object VehicleType {
case object Car extends VehicleType[Car] {
def newReader = new CarReader
}
// ... and so on
}
Then VehicleReader factory method will then look very clean and be completely typesafe:
object VehicleReader {
def apply[T <: Vehicle](vehicleType: VehicleType[T]) = vehicleType.newReader
}
The author of the question
Exchanging type parameters with abstract types wrote a => at the beginning of his class definitions. Example:
abstract class Thing { t =>
type A
type G <: Group { type A = t.A }
val group: G
}
What does the t => mean ?
Because this is hard to find in Google & Co, can someone please give me more background information or provide a link, where I can find more information about this language construct ?
The default naming for class itself is this. You may replace it with t by t =>
It is useful if your class contains subclasses and you need access to enclosing self reference.
Without t => in your example you would write something like this:
abstract class Thing {
type G <: Group { type A = this.A }
}
Group { type A = this.A } is a subtype so this would reference to group specialization itself not to a thing object. Probably you get not what you mean to get. If you need access to Thing self reference you should resolve name conflict by assigning self reference another name
abstract class Thing { another_this = >
type G <: Group { type A = another_this.A}
}
It is indeed self type annotation. See the official Scala specification:
https://scala-lang.org/files/archive/spec/2.13/13-syntax-summary.html
According to this specification, its context free EBNF syntax is:
SelfType ::= id [‘:’ Type] ‘=>’
| ‘this’ ‘:’ Type ‘=>’
So, basically, this means SelfType has two basic forms. In one form, you can use an id with or without Type. In the other, you can use this but it must be accompanied with a Type.
You can find it in section 29.4 of Programming in Scala Second Edition. However, remember that books can be quickly out of date, so you need to refer to the specification.