abstract-type

Scala: implementing method with return type of concrete instance

由 杀马特。学长 韩版系。学妹 提交于 2019-12-03 01:21:35
问题 I need a way to enforce a method in an abstract class to have a return type of the concrete class of the object it is called on. The most common example is a copy() method, and I'm currently using an approach based on abstract types: abstract class A(id: Int) { type Self <: A def copy(newId: Int): Self } class B(id: Int, x: String) extends A(id) { type Self = B def copy(newId: Int) = new B(newId, x) } class C(id: Int, y: String, z: String) extends A(id) { type Self = C def copy(newId: Int) =

Scala abstract types in classes within objects

由 柔情痞子 提交于 2019-12-02 08:54:33
If I do this: object Parent { class Inner extends Testable { type Self <: Inner } def inner = new Inner() } object Child { class Inner extends Parent.Inner { type Self <: Inner } def inner = new Inner() } trait Testable { type Self def test[T <: Self] = {} } object Main { // this works val p: Parent.Inner = Child.inner // this doesn't val h = Parent.inner h.test[Child.Inner] } I get this error: error: type arguments [Child.Inner] do not conform to method test's type parameter bounds [T <: Main.h.Self] h.test[Child.Inner] Why does this error when I my Self type is Parent.Inner and Child.Inner <

Abstract types versus type parameters

由 五迷三道 提交于 2019-11-27 12:07:20
In what situations should abstract types be preferred over type parameters? VonC To add to my previous answer on Abstract type vs. parameters , you have also the JESSE EICHAR's recent blog post (2010, May 3rd) highlighting some key differences: trait C1[A] { def get : A def doit(a:A):A } trait C2 { type A def get : A def doit(a:A):A } In C2 case, the parameter is "buried" (as an internal abstract type). (except, as retronym puts it, it is not actually buried, see below) Whereas with generic type, the parameter is explicitly mentioned, helping other expressions to know what type they are

How to use Scala's this typing, abstract types, etc. to implement a Self type?

由 末鹿安然 提交于 2019-11-27 00:14:11
I couldn't find the answer to this in any other question. Suppose that I have an abstract superclass Abstract0 with two subclasses, Concrete1 and Concrete1. I want to be able to define in Abstract0 something like def setOption(...): Self = {...} where Self would be the concrete subtype. This would allow chaining calls to setOption like this: val obj = new Concrete1.setOption(...).setOption(...) and still get Concrete1 as the inferred type of obj. What I don't want is to define this: abstract class Abstract0[T <: Abstract0[T]] because it makes it harder for clients to handle this type. I tried

Abstract types versus type parameters

由 好久不见. 提交于 2019-11-26 15:54:37
问题 In what situations should abstract types be preferred over type parameters? 回答1: To add to my previous answer on Abstract type vs. parameters, you have also the JESSE EICHAR's recent blog post (2010, May 3rd) highlighting some key differences: trait C1[A] { def get : A def doit(a:A):A } trait C2 { type A def get : A def doit(a:A):A } In C2 case, the parameter is "buried" (as an internal abstract type). (except, as retronym puts it, it is not actually buried, see below) Whereas with generic

Scala: Abstract types vs generics

由 你说的曾经没有我的故事 提交于 2019-11-26 05:40:43
I was reading A Tour of Scala: Abstract Types . When is it better to use abstract types? For example, abstract class Buffer { type T val element: T } rather that generics, for example, abstract class Buffer[T] { val element: T } VonC You have a good point of view on this issue here: The Purpose of Scala's Type System A Conversation with Martin Odersky, Part III by Bill Venners and Frank Sommers (May 18, 2009) Update (October2009): what follows below has actually been illustrated in this new article by Bill Venners: Abstract Type Members versus Generic Type Parameters in Scala (see summary at
订阅 abstract-type