Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

some

  • Loading branch information...
commit 08decc6fd832eed9a629ab1ccae3163e6ce4f6f3 1 parent 2034b55
unknown authored
View
0  src/main/scala/lang/TypeParameterization/Contravarience.scala
No changes.
View
42 src/main/scala/lang/TypeParameterization/ExistentialTypes.scala
@@ -0,0 +1,42 @@
+/*
+immutable collections are almost always covariant in their type parameters.
+ An immutable.List[String] can equally well be treated as an immutable.
+ List[Any] - all the operations are concerned with what values you can get out of the list,
+ so can easily be widened to some supertype.
+ However, a mutable.List is *not* covariant in its type parameter.
+ You might be familiar with the problems that result from treating it as such from Java.
+*/
+
+package lang.TypeParameterization
+
+trait Foo
+
+class Bar[+T] {
+ def doStuff[T <: Foo](args:Array[T]) = {
+ // do something
+ }
+ def doCoolStuff(args : Array[T forSome { type T <: Foo }]) = { //narrows the scope of the type parameter
+ // do something
+ }
+
+ // all violations of type soundness involved some re-assignable field or array element
+/*It turns out that as soon as a generic parameter
+type appears as the type of a method parameter, the containing class or trait
+may not be covariant in that type parameter.*/
+
+}
+
+/*examples of using lower bound to solve covarience type can't be in parameterized method. */
+class Queue[+T] (private val leading: List[T],private val trailing: List[T] ) {
+ def enqueue[U >: T](x: U) = new Queue[U](leading, x :: trailing)
+}
+
+class StrangeIntQueue extends Queue[Int] {
+ override def enqueue(x: Int) = {
+ println(math.sqrt(x))
+ super.enqueue(x)
+ }
+}
+
+//val x: Queue[Any] = new StrangeIntQueue
+//x.enqueue("abc")
View
31 src/main/scala/lang/TypeParameterization/ExistentialTypes.txt
@@ -0,0 +1,31 @@
+Existential types
+
+Existential types are frequently used in connection with record types to represent modules
+and abstract data types, due to their ability to separate implementation from interface.
+For example, the type "T = ∃X { a: X; f: (X → int); }" describes a module interface that
+has a data member of type X and a function that takes a parameter of the same type X and
+returns an integer. This could be implemented in different ways; for example:
+
+ * intT = { a: int; f: (int → int); }
+ * floatT = { a: float; f: (float → int); }
+
+These types are both subtypes of the more general existential type T and correspond to concrete
+implementation types, so any value of one of these types is a value of type T.
+Given a value "t" of type "T", we know that "t.f(t.a)" is well-typed,
+regardless of what the abstract type X is. This gives flexibility for choosing types suited to
+a particular implementation while clients that use only values of the interface type—the
+existential type—are isolated from these choices.
+
+In general it's impossible for the typechecker to infer which existential type a given module
+belongs to. In the above example intT { a: int; f: (int → int); } could also have the type
+∃X { a: X; f: (int → int); }. The simplest solution is to annotate every module with its
+intended type, e.g.:
+
+ * intT = { a: int; f: (int → int); } as ∃X { a: X; f: (X → int); }
+
+Although abstract data types and modules had been implemented in programming languages for
+quite some time, it wasn't until 1988 that John C. Mitchell and Gordon Plotkin established
+the formal theory under the slogan: "Abstract [data] types have existential type".[5]
+The theory is a second-order typed lambda calculus similar to System F,
+but with existential instead of universal quantification.
+
View
0  src/test/scala/lang/TypeParameterization/Contravarience.scala
No changes.
View
12 src/test/scala/lang/TypeParameterization/ExistentialTypesSpec.scala
@@ -0,0 +1,12 @@
+package lang.TypeParameterization
+
+import org.scalatest.Spec
+import org.scalatest.matchers.ShouldMatchers
+
+class ExistentialTypesSpec extends Spec with ShouldMatchers{
+ class SubFoo extends Foo
+ describe("test mutable object with invarient args subtyping"){
+
+ }
+
+}
Please sign in to comment.
Something went wrong with that request. Please try again.