-1

Consider the following situation:

trait  M { } // uses N
object M { def apply = new M { } }
trait  N { self: L =>  }
trait  L { val m: B }
type   B

M needs new trees definitions that are created in N. I don't want to pass around these new trees because the class hierarchy is in fact very long and would result in modifying a lot the code. Instead I was proposed to do:

trait  M { self: N with L => } // uses N
object M { def apply = new M with N with L { } }
trait  N { self: L => }
trait  L { val m: B }
type   B

but then I get error:

object creation impossible, since value m in trait L of type B is not defined

this is coming from the definition of object M. I have tried different combinations and none works.

How can I solve this error?

Discussion

I learn that when writing new M {} I get an anonymous class extending (object??) M, so I tried modifying to new M with N with L {} but then I get the error of unimplemented members from L.

References

You may find more details on the problem on this commit. Namely, type M is MeasureAnnotation, N is StructuralSize and L is SolverProvider.

If you want to build the program you should git clone and then run sbt followed by universal:stage. You need to have installed z3 or cvc4.

user1868607
  • 2,558
  • 1
  • 17
  • 38
  • There is no problem with the code that you gave, so perhaps this is not actually the code that is failing? Please put the failing code *in the question* and ensure that it does actually generate the error that you suggest. – Tim Sep 03 '18 at 17:17
  • @Tim thank you for your observation. the added method apply to object M causes the error – user1868607 Sep 03 '18 at 21:29
  • Unable to recreate stated error. – jwvh Sep 04 '18 at 00:17

1 Answers1

1

I think your code snippet does not accurately reflect your actual commit. In your commit you used a self type on the object, too, which does not make sense. A self-type on a trait describes a requirement that concrete instances mixing in this trait must satisfy. However, an object is already a concrete type, so there is no point in defining further requirements.

In short: do not repeat the self-type from a trait on its companion object.

Jens Halm
  • 489
  • 2
  • 5
  • I am fairly sure though that the exact message is slightly different if you remove the self-annotation from the object. It is hard to comment if you try many things and do not settle with one concrete scenario you want to solve. In any case if you either create an object or a new instance with new A with B with C, you cannot have any abstract members. Both, abstract members and self annotations can only be used in abstract types like traits. – Jens Halm Sep 03 '18 at 21:53
  • Unfortunately I don't have the time to analyze the full implementation, for further help you could try to replicate the issue in a smaller sample like your snippets above. In the snippet you provided it is obvious that it cannot compile: the L trait has an abstract member m, then you try to create an instance of L without defining m. But I'm not sure this correctly reflects your full implementation. – Jens Halm Sep 03 '18 at 22:03