Scala trait and its methods’ parametrization - scala

In my application I want to use such a trait:
trait HasBuffer[+A] {
var items = Buffer[A]()
def add[A](item: A) { items += item }
def remove[A](item: A) { items -= item }
def set(is: Buffer[A]) { items = is }
def clear { items clear }
}
Classes that inherit this trait should be able to buffer any instances of classes who are children of the class A. However on both the add and remove methods the compiler complains about the item being added or removed from the items that "type mismatch; found : item.type (with underlying type A) required: A". How should I understand this? What is my mistake here and what to do?

You are parameterizing the methods with another type parameter A that differs from the one of your class definition. Here's the version you wrote with renamed parameters:
trait HasBuffer[+A] {
var items = Buffer[A]()
def add[B](item: B) = items += item
def remove[B](item: B) { items -= item }
def set(is: Buffer[A]) { items = is }
def clear { items clear }
}
Now it should be clear, why the compiler rejects this.
Instead you can simply write the methods like this:
def add(item: A) = items += item
def remove(item: A) { items -= item }
However, then you will still receive compiler errors stating that covariant type A occurs in contra- and invariant positions.
The point of being covariant is that if you expect a HasBuffer[AnyVal] one may pass in a HasBuffer[Int]. However, if you expect AnyVal and use that type for the add method as well, you would be able to add a completely different type to your HasBuffer[Int]. Hence, the compiler rejects this.
Instead, you will have to provide a lower bound on the type parameter like this:
trait HasBuffer[+A, V <: A] {
var items = Buffer[V]()
def add(item: V) = items += item
def remove(item: V) { items -= item }
def set(is: Buffer[V]) { items = is }
def clear { items clear }
}
With this you may now have methods like the following:
def doSomething[X <: AnyVal](b : HasBuffer[AnyVal, X], e : X) = b.add(e)
This method will work on all sorts of HasBuffer type parameter combinations that satisfy the required lower bound.
Mentally compare this with the idea of not providing a lower bound. Then the method would have become something like this:
// doesn't make much sense!
def doSomething(b : HasBuffer[AnyVal], e : AnyVal) = b.add(e)
If you call this with an object of type HasBuffer[Int] and a Double it'll be all happy. You probably won't be happy lateron though, when you find your buffer that should contain only Ints now contains a Double.

The problem is that you have defined the add and remove methods with respect to another type parameter A that, although it has the same name, is really a new type parameter.
This should get you going:
def add(item: A)
def remove(item: A)
EDIT: Frank is right, I forgot to deal with the fact that Buffer is covariant in A where in the original declaration, A is clearly in a contravariant position. Hence the above is only a partial solution to the OP's problem.

Related

Local variables with the same type( generic type parameter) have incompatible type

This issue is related to compiler behavior described in another issue
I think this is related to the way generics are implemented in compiler, and it has something to do with Inner Class compiler feature. I've a similar question and I know that this could be fixed with
if(m.compare(lowerBound.asInstanceOf[m.Measure]) >= 0) {
But I don't want to cast same type to same type all over my code. There should be good explanation why this happens. Should I fill in compiler bug somewhere ?
Without local variable m - error messages get even more weird.
trait MeasureBase {
type Measure <: MeasureBase
def compare(that: Measure): Int
def score: Double
}
case class DocTerm[Measure <: MeasureBase]
(val docID: Long, val measure:Measure)
extends Ordered[DocTerm[Measure]] {
def score = measure.score
def compare(that: DocTerm[Measure]): Int
= measure.compare(that.measure.asInstanceOf[measure.Measure])
}
class WriteCacheIterator[Measure <: MeasureBase]
(data:mutable.ArrayBuffer[DocTerm[Measure]]) {
var position = 0
def Next(lowerBound:Measure):Option[DocTerm[Measure]] = {
if(position < data.size - 1){
val m:Measure = data(position).measure
val b:Measure = lowerBound
if(m.compare(b) >= 0) {
//gives compiler error
//Error:(39, 20) type mismatch;
//found : b.type (with underlying type Measure)
//required: m.Measure
//if(m.compare(b) >= 0) {
}
} else return None
}
}
You have two different definitions for Measure:
the type parameter in DocTerm and other places, which is a subtype of MeasureBase.
a type member inside MeasureBase.
The two have nothing in common (except the name, but they are really different things). There is nothing linking your generic Measure inside WriteCacheIterator to the type member called Measure inside each and every element in your ArrayBuffer. You need to refactor the code to make this constraint explicit.
You could probably refactor the code to only use type parameters (generics) everywhere.
trait MeasureBase[Self <: MeasureBase[Self]] {...}
case class DocTerm[M <: MeasureBase[M](val docID: Long, val measure: M)
...

Scala child listbuffer returned as parent listbuffer

I have started working on scala now. And come to a point where I want to use Inheritance correctly.
I am stuck at once place. I have tried to read docs and other information online. but I seems like I am stuck.
Please look at this and tell me if you have faced this in the past and whether I am doing something really really wrong.
So, this is my method:
def getFacethierarchy): ListBuffer[BaseClass] = {
val obj: Childclass = new ChildClass(1, "2")
val list: ListBuffer[ChildClass] = ListBuffer[ChildClass]()
list += obj
list
}
class BaseClass(var id: Int){
}
class ChildClass(id: Int, var name: String) extends BaseClass(id){
}
Now scala Is not allowing me to return a ChildClass instance.
In Java, this would work (Child is a type of Parent)
I tried to change my method signature to return "Any".
I am not sure what I am going wrong with.
Please help, if possible.
update:
To be more specific to what I am doing, I have updated the code snippet.
ListBuffer[ChildClass] is not a subtype of ListBuffer[BaseClass] because ListBuffer being a mutable data structure, it would break the type-safety.
You want to avoid something like:
val l : ListBuffer[Int] = ListBuffer[Int](1, 2, 3)
val l2 :ListBuffer[Any] = l
l2(0) = 2.54
What you can do is to simply create a ListBuffer[BaseClass]:
def getFacethierarchy): ListBuffer[BaseClass] = {
val obj: Chlidclass = new ChildClass(1, "2")
ListBuffer[BaseClass](obj)
}
The problem stems from the fact that ListBuffer is invariant, not covariant (no + before T). It cannot be covariant. For this reason, the ListBuffer[ChildClass] is not a subtype of ListBuffer[BaseClass], even if ChildClass is a subtype of BaseClass.
You can use existential types (: ListBuffer[T] forSome {type T <: BaseClass} (hope I used the correct syntax)), or provide an additional type parameter to the method you want to use (yourMethod[T <: BaseClass]: ListBuffer[T]). If you want "MyTypes" (might be, hard to tell without further details): Scala do not support it.
Taking a closer look at your code, you might prefer to return a List[BaseClass] instead, which is covariant, so you could write:
def getFacethierarchy: List[BaseClass] = {
val obj: Chlidclass = new ChildClass(1, "2")
val list: ListBuffer[ChildClass] = ListBuffer[ChildClass]()
list += obj
list.toList
}

Using scala generics and manifest to cast within a class

I have two classes, Holders (for lack of a better name at the moment) and Holder.
Holder has to be interfaced through Holders, which has an array of Holder of any type.
As such, it has to take Any type. I want to have the setValue do type checking that the Any input is indeed of type T.
I've read a bit about using manifests, but I'm getting somewhat lost. Is there any way to do what I want?
class Holders {
var values = Array[Any]()
var _holders = Array[Holder[_]]()
def setData(index: Int, newValue: Any) {
values(index) = newValue
_holders(index).setValue(newValue)
}
}
class Holder[T](someData: String, initValue: T) {
private var value : T = initValue
def getValue : T = value
def setValue(newValue: Any)(implicit m: Manifest[T]) = {
if (newValue.isInstanceOf[T])
value = newValue.asInstanceOf[T]
}
}
You can.
note: Manifest is deprecated and replaced with TypeTag and ClassTag, but that doesn't affect the remainder of this answer
Often when wanting Manifests/TypeTags you know exactly what's happening at compile time but want that information preserved through to runtime as well. In this case you also have to deal with the fact that, even at compile time, _holders(index) can't tell you what kind of Holder it's returning.
Depending on how _holders will be built, it may be possible to replace it with an Heterogeneous Map from the shapeless library, that would do exactly what you need out-of-the-box.
Otherwise, you have the right idea, testing the type at runtime. The trick is using TypeTag to capture both the underlying type of the holder and the type of the new value.
Note that the TypeTag context bound has to be specified on all the nested methods so it can be passed down the call stack in implicit scope. Presence of the TypeTag is what allows typeOf to then work.
import scala.reflect.runtime.universe._ //for TypeTag
class Holders {
var values = Array[Any]()
var _holders = Array[Holder[_]]()
def setData[V: TypeTag](index: Int, newValue: V): Unit = {
values(index) = newValue
_holders(index).setValue(newValue)
}
}
class Holder[T: TypeTag](someData: String, initValue: T) {
private var value: T = initValue
def getValue: T = value
def setValue[V: TypeTag](newValue: V): Unit =
if(typeOf[V] <:< typeOf[T]) {
value = newValue.asInstanceOf[T]
}
Or using Manifest
class Holder[T: Manifest](someData: String, initValue: T) {
private var value: T = initValue
def getValue: T = value
def setValue[V: Manifest](newValue: V): Unit =
if(manifest[V] <:< manifest[T]) {
value = newValue.asInstanceOf[T]
}
I'd strongly urge you to favour TypeTag though!
Type erasure makes this kind of thing... hard. In a nutshell once your code is compiled, all type parameters are replaced with Any. To understand the implications, consider the following example:
trait Foo[T] { def isT(a: Any): Boolean = a.isInstanceOf[T] }
object Bar extends Foo[String]
Bar.isT("foo") // true
Bar.isT(42) // also true, as Int <: Any
This will produce a warning when compiled with the appropriate options.
In this scenario you have two options; you can compare TypeTags, in which case you hope that the provided type parameters are sufficiently accurate (consider the provided type parameter could be any superclass of value), or you compare the runtime classes of your values (in which case you are out of luck when dealing with generic types). A TypeTag-based solution might look something like this:
class Holder[T : TypeTag](someData: String, initValue: T) {
private var value = initValue
def setValue[V : TypeTag](v: V): Unit = {
// Works because there are TypeTags for T and V in implicit scope
if(typeOf[V] <:< typeOf[T])
value = v.asInstanceOf[T]
}
}
Now you are looking at this and saying "well doesn't that mean that the assignment is actually value = v.asInstanceOf[Any]?" and the answer is yes - value is also erased to Any. Casting does nothing, in the sense that v.asInstanceOf[T] does not mean "convert v to a T". Instead what you are doing is saying "oh yeah, v is totally a T - honest!", and because the compiler is naive, it believes you.

Scala: Building a complex hierarchy of traits and classes

I have posted several questions on SO recently dealing with Scala traits, representation types, member types, manifests, and implicit evidence. Behind these questions is my project to build modeling software for biological protein networks. Despite the immensely helpful answers, which have gotten me closer than I ever could get on my own, I have still not arrived at an solution for my project. A couple of answers have suggested that my design is flawed, which is why the solutions to the Foo-framed questions don't work in practice. Here I am posting a more complicated (but still greatly simplified) version of my problem. My hope is that the problem and solution will be broadly useful for people trying to build complex hierarchies of traits and classes in Scala.
The highest-level class in my project is the biological reaction rule. A rule describes how one or two reactants are transformed by a reaction. Each reactant is a graph that has nodes called monomers and edges that connect between named sites on the monomers. Each site also has a state that it can be in. Edit: The concept of the edges have been removed from the example code because they complicate the example without contributing much to the question. A rule might say something like this: there is one reactant made of monomer A bound to monomer B through sites a1 and b1, respectively; the bond is broken by the rule leaving sites a1 and b1 unbound; simultaneously on monomer A, the state of site a1 is changed from U to P. I would write this as:
A(a1~U-1).B(b1-1) -> A(a1~P) + B(b1)
(Parsing strings like this in Scala was so easy, it made my head spin.) The -1 indicates that bond #1 is between those sites--the number is just a arbitrary label.
Here is what I have so far along with the reasoning for why I added each component. It compiles, but only with gratuitous use of asInstanceOf. How do I get rid of the asInstanceOfs so that the types match?
I represent rules with a basic class:
case class Rule(
reactants: Seq[ReactantGraph], // The starting monomers and edges
producedMonomers: Seq[ProducedMonomer] // Only new monomers go here
) {
// Example method that shows different monomers being combined and down-cast
def combineIntoOneGraph: Graph = {
val all_monomers = reactants.flatMap(_.monomers) ++ producedMonomers
GraphClass(all_monomers)
}
}
The class for graphs GraphClass has type parameters because so that I can put constraints on what kinds of monomers and edges are allowed in a particular graph; for example, there cannot be any ProducedMonomers in the Reactant of a Rule. I would also like to be able to collect all the Monomers of a particular type, say ReactantMonomers. I use type aliases to manage the constraints.
case class GraphClass[
+MonomerType <: Monomer
](
monomers: Seq[MonomerType]
) {
// Methods that demonstrate the need for a manifest on MonomerClass
def justTheProductMonomers: Seq[ProductMonomer] = {
monomers.collect{
case x if isProductMonomer(x) => x.asInstanceOf[ProductMonomer]
}
}
def isProductMonomer(monomer: Monomer): Boolean = (
monomer.manifest <:< manifest[ProductStateSite]
)
}
// The most generic Graph
type Graph = GraphClass[Monomer]
// Anything allowed in a reactant
type ReactantGraph = GraphClass[ReactantMonomer]
// Anything allowed in a product, which I sometimes extract from a Rule
type ProductGraph = GraphClass[ProductMonomer]
The class for monomers MonomerClass has type parameters, as well, so that I can put constraints on the sites; for example, a ConsumedMonomer cannot have a StaticStateSite. Furthermore, I need to collect all the monomers of a particular type to, say, collect all the monomers in a rule that are in the product, so I add a Manifest to each type parameter.
case class MonomerClass[
+StateSiteType <: StateSite : Manifest
](
stateSites: Seq[StateSiteType]
) {
type MyType = MonomerClass[StateSiteType]
def manifest = implicitly[Manifest[_ <: StateSiteType]]
// Method that demonstrates the need for implicit evidence
// This is where it gets bad
def replaceSiteWithIntersection[A >: StateSiteType <: ReactantStateSite](
thisSite: A, // This is a member of this.stateSites
monomer: ReactantMonomer
)(
// Only the sites on ReactantMonomers have the Observed property
implicit evidence: MyType <:< ReactantMonomer
): MyType = {
val new_this = evidence(this) // implicit evidence usually needs some help
monomer.stateSites.find(_.name == thisSite.name) match {
case Some(otherSite) =>
val newSites = stateSites map {
case `thisSite` => (
thisSite.asInstanceOf[StateSiteType with ReactantStateSite]
.createIntersection(otherSite).asInstanceOf[StateSiteType]
)
case other => other
}
copy(stateSites = newSites)
case None => this
}
}
}
type Monomer = MonomerClass[StateSite]
type ReactantMonomer = MonomerClass[ReactantStateSite]
type ProductMonomer = MonomerClass[ProductStateSite]
type ConsumedMonomer = MonomerClass[ConsumedStateSite]
type ProducedMonomer = MonomerClass[ProducedStateSite]
type StaticMonomer = MonomerClass[StaticStateSite]
My current implementation for StateSite does not have type parameters; it is a standard hierarchy of traits, terminating in classes that have a name and some Strings that represent the appropriate state. (Be nice about using strings to hold object states; they are actually name classes in my real code.) One important purpose of these traits is provide functionality that all the subclasses need. Well, isn't that the purpose of all traits. My traits are special in that many of the methods make small changes to a property of the object that is common to all subclasses of the trait and then return a copy. It would be preferable if the return type matched the underlying type of the object. The lame way to do this is to make all the trait methods abstract, and copy the desired methods into all the subclasses. I am unsure of the proper Scala way to do this. Some sources suggest a member type MyType that stores the underlying type (shown here). Other sources suggest a representation type parameter.
trait StateSite {
type MyType <: StateSite
def name: String
}
trait ReactantStateSite extends StateSite {
type MyType <: ReactantStateSite
def observed: Seq[String]
def stateCopy(observed: Seq[String]): MyType
def createIntersection(otherSite: ReactantStateSite): MyType = {
val newStates = observed.intersect(otherSite.observed)
stateCopy(newStates)
}
}
trait ProductStateSite extends StateSite
trait ConservedStateSite extends ReactantStateSite with ProductStateSite
case class ConsumedStateSite(name: String, consumed: Seq[String])
extends ReactantStateSite {
type MyType = ConsumedStateSite
def observed = consumed
def stateCopy(observed: Seq[String]) = copy(consumed = observed)
}
case class ProducedStateSite(name: String, Produced: String)
extends ProductStateSite
case class ChangedStateSite(
name: String,
consumed: Seq[String],
Produced: String
)
extends ConservedStateSite {
type MyType = ChangedStateSite
def observed = consumed
def stateCopy(observed: Seq[String]) = copy(consumed = observed)
}
case class StaticStateSite(name: String, static: Seq[String])
extends ConservedStateSite {
type MyType = StaticStateSite
def observed = static
def stateCopy(observed: Seq[String]) = copy(static = observed)
}
My biggest problems are with methods framed like MonomerClass.replaceSiteWithIntersection. A lot of methods do some complicated search for particular members of the class, then pass those members to other functions where complicated changes are made to them and return a copy, which then replaces the original in a copy of the higher-level object. How should I parameterize methods (or the classes) so that the calls are type safe? Right now I can get the code to compile only with lots of asInstanceOfs everywhere. Scala is particularly unhappy with passing instances of a type or member parameter around because of two main reasons that I can see: (1) the covariant type parameter ends up as input to any method that takes them as input, and (2) it is difficult to convince Scala that a method that returns a copy indeed returns an object with exactly the same type as was put in.
I have undoubtedly left some things that will not be clear to everyone. If there are any details I need to add, or excess details I need to delete, I will try to be quick to clear things up.
Edit
#0__ replaced the replaceSiteWithIntersection with a method that compiled without asInstanceOf. Unfortunately, I can't find a way to call the method without a type error. His code is essentially the first method in this new class for MonomerClass; I added the second method that calls it.
case class MonomerClass[+StateSiteType <: StateSite/* : Manifest*/](
stateSites: Seq[StateSiteType]) {
type MyType = MonomerClass[StateSiteType]
//def manifest = implicitly[Manifest[_ <: StateSiteType]]
def replaceSiteWithIntersection[A <: ReactantStateSite { type MyType = A }]
(thisSite: A, otherMonomer: ReactantMonomer)
(implicit ev: this.type <:< MonomerClass[A])
: MonomerClass[A] = {
val new_this = ev(this)
otherMonomer.stateSites.find(_.name == thisSite.name) match {
case Some(otherSite) =>
val newSites = new_this.stateSites map {
case `thisSite` => thisSite.createIntersection(otherSite)
case other => other
}
copy(stateSites = newSites)
case None => new_this // This throws an exception in the real program
}
}
// Example method that calls the previous method
def replaceSomeSiteOnThisOtherMonomer(otherMonomer: ReactantMonomer)
(implicit ev: MyType <:< ReactantMonomer): MyType = {
// Find a state that is a current member of this.stateSites
// Obviously, a more sophisticated means of selection is actually used
val thisSite = ev(this).stateSites(0)
// I can't get this to compile even with asInstanceOf
replaceSiteWithIntersection(thisSite, otherMonomer)
}
}
I have reduced your problem to traits, and I am starting to understand why you are getting into troubles with casts and abstract types.
What you are actually missing is ad-hoc polymorphism, which you obtain through the following:
- Writing a method with generic signature relying on an implicit of the same generic to delegate the work to
- Making the implicit available only for specific value of that generic parameter, which will turn into a "implicit not found" compile time error when you try to do something illegal.
Let's now look to the problem in order. The first is that the signature of your method is wrong for two reasons:
When replacing a site you want to create a new monomer of the new generic type, much as you do when you add to a collection an object which is a superclass of the existing generic type: you get a new collection whose type parameter is the superclass. You should yield this new Monomer as a result.
You are not sure that the operation will yield a result (in case you can't really replace a state). In such a case the right type it's Option[T]
def replaceSiteWithIntersection[A >: StateSiteType <: ReactantStateSite]
(thisSite: A, monomer: ReactantMonomer): Option[MonomerClass[A]]
If we now look digger in the type errors, we can see that the real type error comes from this method:
thisSite.createIntersection
The reason is simple: it's signature is not coherent with the rest of your types, because it accepts a ReactantSite but you want to call it passing as parameter one of your stateSites (which is of type Seq[StateSiteType] ) but you have no guarantee that
StateSiteType<:<ReactantSite
Now let's see how evidences can help you:
trait Intersector[T] {
def apply(observed: Seq[String]): T
}
trait StateSite {
def name: String
}
trait ReactantStateSite extends StateSite {
def observed: Seq[String]
def createIntersection[A](otherSite: ReactantStateSite)(implicit intersector: Intersector[A]): A = {
val newStates = observed.intersect(otherSite.observed)
intersector(newStates)
}
}
import Monomers._
trait MonomerClass[+StateSiteType <: StateSite] {
val stateSites: Seq[StateSiteType]
def replaceSiteWithIntersection[A >: StateSiteType <: ReactantStateSite](thisSite: A, otherMonomer: ReactantMonomer)(implicit intersector:Intersector[A], ev: StateSiteType <:< ReactantStateSite): Option[MonomerClass[A]] = {
def replaceOrKeep(condition: (StateSiteType) => Boolean)(f: (StateSiteType) => A)(implicit ev: StateSiteType<:<A): Seq[A] = {
stateSites.map {
site => if (condition(site)) f(site) else site
}
}
val reactantSiteToIntersect:Option[ReactantStateSite] = otherMonomer.stateSites.find(_.name == thisSite.name)
reactantSiteToIntersect.map {
siteToReplace =>
val newSites = replaceOrKeep {_ == thisSite } { item => thisSite.createIntersection( ev(item) ) }
MonomerClass(newSites)
}
}
}
object MonomerClass {
def apply[A <: StateSite](sites:Seq[A]):MonomerClass[A] = new MonomerClass[A] {
val stateSites = sites
}
}
object Monomers{
type Monomer = MonomerClass[StateSite]
type ReactantMonomer = MonomerClass[ReactantStateSite]
type ProductMonomer = MonomerClass[ProductStateSite]
type ProducedMonomer = MonomerClass[ProducedStateSite]
}
Please note that this pattern can be used with no special imports if you use in a clever way implicit resolving rules (for example you put your insector in the companion object of Intersector trait, so that it will be automatically resolved).
While this pattern works perfectly, there is a limitation connected to the fact that your solution works only for a specific StateSiteType. Scala collections solve a similar problem adding another implicit, which is call CanBuildFrom. In our case we will call it CanReact
You will have to make your MonomerClass invariant, which might be a problem though (why do you need covariance, however?)
trait CanReact[A, B] {
implicit val intersector: Intersector[B]
def react(a: A, b: B): B
def reactFunction(b:B) : A=>B = react(_:A,b)
}
object CanReact {
implicit def CanReactWithReactantSite[A<:ReactantStateSite](implicit inters: Intersector[A]): CanReact[ReactantStateSite,A] = {
new CanReact[ReactantStateSite,A] {
val intersector = inters
def react(a: ReactantStateSite, b: A) = a.createIntersection(b)
}
}
}
trait MonomerClass[StateSiteType <: StateSite] {
val stateSites: Seq[StateSiteType]
def replaceSiteWithIntersection[A >: StateSiteType <: ReactantStateSite](thisSite: A, otherMonomer: ReactantMonomer)(implicit canReact:CanReact[StateSiteType,A]): Option[MonomerClass[A]] = {
def replaceOrKeep(condition: (StateSiteType) => Boolean)(f: (StateSiteType) => A)(implicit ev: StateSiteType<:<A): Seq[A] = {
stateSites.map {
site => if (condition(site)) f(site) else site
}
}
val reactantSiteToIntersect:Option[ReactantStateSite] = otherMonomer.stateSites.find(_.name == thisSite.name)
reactantSiteToIntersect.map {
siteToReplace =>
val newSites = replaceOrKeep {_ == thisSite } { canReact.reactFunction(thisSite)}
MonomerClass(newSites)
}
}
}
With such an implementation, whenever you want to make the possibility to replace a site with another site of a different type, all you need is to make available new implicit instances of CanReact with different types.
I will conclude with a (I hope) clear explanation of why you should not need covariance.
Let's say you have a Consumer[T] and a Producer[T].
You need covariance when you want to provide to the Consumer[T1] a Producer[T2] where T2<:<T1 . But if you need to use the value produced by T2 inside T1, you can
class ConsumerOfStuff[T <: CanBeContained] {
def doWith(stuff: Stuff[T]) = stuff.t.writeSomething
}
trait CanBeContained {
def writeSomething: Unit
}
class A extends CanBeContained {
def writeSomething = println("hello")
}
class B extends A {
override def writeSomething = println("goodbye")
}
class Stuff[T <: CanBeContained](val t: T)
object VarianceTest {
val stuff1 = new Stuff(new A)
val stuff2 = new Stuff(new B)
val consumerOfStuff = new ConsumerOfStuff[A]
consumerOfStuff.doWith(stuff2)
}
This stuff clearly not compiles:
error: type mismatch; found : Stuff[B] required: Stuff[A] Note: B <:
A, but class Stuff is invariant in type T. You may wish to define T as
+T instead. (SLS 4.5) consumerOfStuff.doWith(stuff2).
But again, this come from a misinterpretation of usage of variance, as How are co- and contra-variance used in designing business applications? Kris Nuttycombe answer explain. If we refactor like the following
class ConsumerOfStuff[T <: CanBeContained] {
def doWith[A<:T](stuff: Stuff[A]) = stuff.t.writeSomething
}
You could see everything compiling fine.
Not an answer, but what I can observe from looking over the question:
I see MonomerClass but not Monomer
My guts say you should avoid manifests when possible, as you have seen they can make things complicated. I don't think you will need them. For example the justTheProductMonomers method in GraphClass – since you have complete control over your class hierarchy, why not add test methods for anything involving runtime checks to Monomer directly? E.g.
trait Monomer {
def productOption: Option[ProductMonomer]
}
then you'll have
def justTheProductMonomers : Seq[ProductMonomer] = monomers.flatMap( _.productOption )
and so forth.
The problem here is that it seems you can have a generic monomer satisfying the product predicate, while you somehow want sub-type ProductMonomer.
The general advise I would give is first to define your matrix of tests that you need to process the rules, and then put those tests as methods into the particular traits, unless you have a flat hierarchy for which you can do pattern matching, which is easier since the disambiguation will appear concentrated at your use site, and not spread across all implementing types.
Also don't try to overdue it with compile-time type constraints. Often it's perfectly fine to have some constraints checked at runtime. That way at least you can construct a fully working system, and then you can try to spot the points where you can convert a runtime check into a compile time check, and decide whether the effort is worth it or not. It is appealing to solve things on the type level in Scala, because of its sophistication, but it also requires the most skills to do it right.
There are multiple problems. First, the whole method is weird: On the one hand you passing in a monomer argument, and if the argument thisState is found, the method has nothing to do with the receiver—then why is this a method in MonomerClass at all and not a "free floating" function—, on the other hand you fall back to returning this if thisSite is not found. Since you originally had also implicit evidence: MyType <:< ReactantMonomer, my guess is the whole monomer argument is obsolete, and you actually wanted to operate on new_this.
A bit of cleanup, forgetting the manifests for the moment, you could have
case class MonomerClass[+StateSiteType <: StateSite, +EdgeSiteType <: EdgeSite](
stateSites: Seq[StateSiteType], edgeSites: Seq[EdgeSiteType]) {
def replaceSiteWithIntersection[A <: ReactantStateSite { type MyType = A }]
(thisSite: A)(implicit ev: this.type <:< MonomerClass[A, ReactantEdgeSite])
: MonomerClass[A, ReactantEdgeSite] = {
val monomer = ev(this)
monomer.stateSites.find(_.name == thisSite.name) match {
case Some(otherSite) =>
val newSites = monomer.stateSites map {
case `thisSite` => thisSite.createIntersection(otherSite)
case other => other
}
monomer.copy(stateSites = newSites)
case None => monomer
}
}
}
This was an interesting problem, it took me some iterations to get rid of the (wrong!) casting. Now it is actually quite readable: This method is restricted to the evidence that StateSiteType is actually a subtype A of ReactantStateSite. Therefore, the type parameter A <: ReactantStateSite { type MyType = A }—the last bit is interesting, and this was a new find for myself: You can specify the type member here to make sure that your return type from createIntersection is actually A.
There is still something odd with your method, because if I'm not mistaken, you will end up calling x.createIntersection(x) (intersecting thisSite with itself, which is a no-op).
One thing that is flawed about replaceSiteWithIntersection is that according to the method signature the type of thisSite (A) is a super-type of StateSiteType and a sub-type of ReactantStateSite.
But then you eventually cast it to StateSiteType with ReactantStateSite. That doesn't make sense to me.
Where do you get the assurance from that A suddenly is a StateSiteType?

Scala anonymous class type mismatch

I am creating a list holding Comparable objects and wish to create one object that serves as the minimum of the list, such that it always returns -1 for its compareTo method. Other methods in the list, like print here requires an input of type A. If I compile the code I get the following error:
error: type mismatch;
found : java.lang.Object with java.lang.Comparable[String]
required: String
l.print(l.min)
Anyone have any idea about how can a create such a minimum element so that it is always smaller than any other elements in the list?
class MyList[A <: Comparable[A]] {
val min = new Comparable[A] {
def compareTo(other: A) = -1
}
def print(a: A) = {
println(a)
}
}
class Run extends Application {
val l = new MyList[String]
l.print(l.min)
}
Well, the input passed is not equal to the input provided, right? print needs an A:
def print(a: A) = {
And min does not return an A:
val min = new Comparable[A] {
As to creating such an A as you want it... how could you possibly go about it? You don't know anything about A -- you don't know what its toString returns, you don't know what methods it implements, etc.
So, basically, change your algorithm.
You are getting a compile error because you're trying to use a Comparable where the compiler is expecting a A, what you really want to do is:
val min: A = new A {
def compareTo(other: A) = -1
}
but you can't do this in Scala (or Java), because you're trying to create an object of an unknown type (A). You could do this using reflection, but you would still have the problem of creating an object which was less than any other object in the list.
Also, be aware that your implementation of compareTo will have problems with almost any sorting algorithm you choose, because you can't guarantee compareTo is always called from min. For example, you could get:
min.compareTo(list(0)) // returns -1
list(0).compareTo(min) // could be anything really
If you want a list that returns a specific object as the 'minimum' then you could just prepend a specific value to the sorted list:
class MyList2[A <: Comparable[A]] {
val min: A; // somehow create an instance of the class A
val list: List[A]
def sort(fn: (A, A) => Boolean) = {
min :: list.sort(fn)
}
}
but as Daniel says, this is probably the wrong way to go about it.