I ran into an interesting scenario in Scala. It seems then I have a base trait that defines other traits, the implementation cannot find the base trait not matter what.
I created this base trait simple for convenience that I don't need to redefined these traits on every implementation. Do anyone know why this doesn't work?
object Base {
trait Create
trait Delete
}
trait BaseTrait {
trait Create extends Base.Create
trait Delete extends Base.Delete
}
object Implementation extends BaseTrait
object Something {
class SomeClass extends Implementation.Create //The trait is not defined.
}
Update:
The question has been cleared up a bit so that its more precise. The solution as #BrianHsu pointed out is that trait cannot be inherited.
This block of code is fine:
object Base {
trait Event
trait Command
}
The following block will run into to trouble:
trait BaseTrait {
trait Event extends Event
trait Command extends Command
}
But Scala compiler says it very clearly.
test.scala:7: error: illegal cyclic reference involving trait Event
trait Event extends Event
^
test.scala:8: error: illegal cyclic reference involving trait Command
trait Command extends Command
Of course you cannot do this, just like you could not do the following in Java:
class HelloWorld extends HelloWorld
You have to specify that what you extend is actually Base.Event / Base.Command, so it will only work if you write it as:
trait BaseTrait {
trait Event extends Base.Event
trait Command extends Base.Command
}
Another problem in your code it the last Something object, it does not make sense at all:
object Something {
Implementation.Event
Implementation.Commannd
}
So compiler give you a clear error message:
test.scala:14: error: value Event is not a member of object Implementation
Implementation.Event
^
test.scala:15: error: value Commannd is not a member of object Implementation
Implementation.Commannd
It's quite obvious, an trait in Scala is much like interface in Java, you should not use it as it is a field.
Related
An easy thing to do in many languages but not in Scala is:
Define archetype 'Super', such that all implementations of 'Super' has to define a constructor 'create()'.
I found this constraint very important and is able to identify a lot of problems before runtime. However this feature is only partially enforced in Java (by defining an 'abstract' static method that always throws an error) and completely missing in Scala (companion object is completely detached from class and cannot be enforced in archetype).
is there a macro or tool that allows me to do this?
UPDATE Sorry my question was missing context and examples. Here is a formal use case in scala:
In project A, we define an interface that can be extended by all subprojects:
trait AbstractFoo {}
This interface should always have a default 0-parameter builder/constructor, so project A can initialize it on-demand, however, the implementation of each constructor is unknown to project A:
object AbstractFoo {
def default[T <: AbstractFoo: ClassTag](): T
}
So the problem becomes: How to rigorously define AbstractFoo, such that for all subprojects of A, any implementation(s) of AbstractFoo:
case class Foo(...) extends AbstractFoo
must satisfy:
'Foo' must have a 0-parameter builder/constructor defined (presumably in its companion object)
calling AbstractFoo.defaultFoo can invoke this 0-parameter builder/constructor
It should be noted that in an alternative conditions, a solution exists which is to define every companion object as an implicit type class:
trait FooBuilder[T <: AbstractFoo] {
def default(): T
}
object AbstractFoo {
implicit object Foo extends FooBuilder[Foo] {
def default() = {...}
}
def default[T <: AbstractFoo: FooBuilder](): T = {
implicitly[FooBuilder[T]].default
}
}
Such that if the implicit object is undefined the compiler will give an implicit not found error (my code snippet may have some syntax error, the idea is from http://www.cakesolutions.net/teamblogs/demystifying-implicits-and-typeclasses-in-scala)
Unfortunately it's not always convenient, because this subproject of A is usually unknown to project A. Yet the default implicit builder cannot be redefined, this makes every invocation of default() more covoluted.
I believe scala is a very extendable language, so there should be at least 1 way to enforce it whether if using macro, annotation or other metaprogramming techniques. Is my question clear enough now?
UPDATE2: I believe I found the solution after carefully study Scaladoc, there is a comment hidden in a corner:
if there are several eligible arguments which match the implicit parameter’s type, a most specific one will be chosen using the rules of static overloading resolution (see Scala Specification §6.26.4):
...
Implicit scope of type arguments (2.8.0)
...
So all I need is to write an implicit function in FooBuilder:
trait FooBuilder[T <: AbstractFoo] {
def default(): T
implicit def self = this
}
object Foo extends FooBuilder[Foo]
So everytime someone call:
default[Foo]
scala will refer to the scope of class Foo, which include object Foo, which contains the implicit value Foo, and eventually find the 0-parameter constructor.
I think this definition is better than defining it under object FooBuilder, since you can only define FooBuilder once, thus its not quite extendable. Would you agree with me? If so, could you please revise your answer so I can award you point?
I don't understand why an abstract class or even a Trait won't allow this to be done?
abstract class DefineCreate{
def create(): Unit
}
case class Foo(one: Int)
object Foo extends DefineCreate{
def create(): Unit = { Console.out.println("side-effect") }
}
Thus I force a user to make a create method on the object in question because all implementations of DefineCreate must do so in order to compile.
Update Following Comments
Well, without having to resort to macros and the like, you could achieve the same sort of thing with type classes:
trait Constructor[A]{
def create(): A
}
object Construct{
def create[A](implicit cr: Constructor[A]): A = cr.create()
}
Which doesn't explicitly force the companion object to sprout methods but it does force a user to make the type class if they want to use the Constructor.create[Foo] pattern.
What is the meaning of <% in Scala?
The context I see it in is an abstract class declaration that I am trying to extend. This is the important part of the class:
abstract class Index[Res <% Result[Res]] {
def results (term: String) : List[Res] ...
This is the header of the Result trait:
trait Result[T] extends Any {
I was able to successfully create a class that extends Result. For simplification here, I will use this header:
class Sample extends Result[Int] {
I want results in my class (extending Index) to return type List[Sample]. I tried a few different definitions, but I always get a similar error:
No implicit view available from [type] to Result[type]
where type is whatever type I used to extend Index, i.e. :
class SampleIndex extends Index[Sample]
I think my problem comes from my misunderstanding of the <% in the definition of the abstract class. Any idea how to fix this?
It's a view bound. check more info here
I have an abstract class Model from which I create case classes:
abstract class Model
case class User(.) extends Model
an abstract class Table taking such a Model as type parameter, used in one of its default concrete methods:
abstract class Table[M <: Model] {
def parser = SomeExternalBuilder[M]
}
The meaning is rather simple: "Give every instance of Table a default parser based on its own class".
The problem is that SomeExternalBuilder will only accept a case class as argument ("case class expected: M"), so it does not compile.
Can I make Table take only case classes as type parameter?
I have seen a few answers providing a missing copy method (ref1, ref2), so I tried this:
trait Model[T] {
def copy: T
}
abstract class Table[M <: Model[M]]
but now case class User extends Model[User] and must overwrite copy too, every function creating a Model takes a type parameter, and honestly the code quickly starts being atrocious, all that for that single line in Table.
Is there no better way than copying that def parser line in every child's body?
Edit: N.B. The real function is def parser: anorm.Macro.namedParser[M] from the "anorm" library for Play.
Edit: Source of the type check by this macro: https://github.com/playframework/anorm/blob/0a1b19055ba3e3749044ad8a54a6b2326235f7c8/core/src/main/scala/anorm/Macro.scala#L117
The problem is that SomeExternalBuilder will only accept a case class as argument ("case class expected: M"), so it does not compile.
I don't think you can ever get such a message from Scala compiler itself, which means that SomeExternalBuilder.apply is a macro. It requires a specific case class in order to know its fields, so that it doesn't matter if you could limit M to be a case class (which you can't): it still wouldn't accept a type parameter.
What you can do is create a macro annotation, so that when you write e.g.
#HasModel
class SomeTable extends Table[SomeModel] {
...
}
the val parser = namedParser[SomeModel] is generated automatically.
Alternately, write #HasModel[SomeModel] class SomeTable { ... } and generate extends Table[SomeModel] as well.
It wouldn't be hard (as macros go), but you still need to annotate each class extending Table.
Not fool proof solution but worth a try
case classes extend Product and Serialisable. Constraint Product with Serialisable will help you get some type safety. M can be any class which extends Product with Serialisable. But Product is extended by case class mostly
abstract class Table[M <: (Product with Serializable)] {
def parser = SomeExternalBuilder[M]
}
So here is the problematic code:
trait World {
type State
def dynamics(s: State): State
// ...
}
trait GridWorld extends World {
class State {...} // concrete
def dynamics(s: State) = s // concrete
// some other staff still abstract
}
trait SimpleGridWorld extends GridWorld {
class State extends super.State {...} // concrete
def foo {dynamics(new State)} // compiler error
}
The compiler says that, dynamics in both World and GridWorld match the signature. However, in World it is abstract and then implemented in GridWorld, so it seems to me that it is clear that I am calling GridWorld.this.dynamics.
Another thing I noticed is that, if I remove the extends super.State in SimpleGridWorld, everything works fine (which I don't understand why, and I do need the functionalities defined in GridWorld.State here). Any explanations? Thanks!
UPDATE
Anyway I am seeing my design pattern quite weird, since if State in SimpleGridWorld does not inherit GridWorld.this.State, dynamics would refer to the unimplemented one defined in the root trait World (which makes sense because the implementation in GridWorld may use the functionalities of GridWorld.this.State which may not exist in SimpleGridWorld.this.State). But what I want is:
XXXWorld.this.State must inherit its super.State (or just use it)
dynamics always refers to super.dynamics if implemented in the super trait/class unless overrided here.
How can I do this? I think it is not a totally irrelevant question, and probably the answer to the previous one would tell me how to redesign my pattern.
How about:
trait World {
type State
def dynamics(s: State): State
}
trait GridWorld extends World {
type State = MyState
class MyState {} // concrete
def dynamics(s: State) = s // concrete
}
trait SimpleGridWorld extends GridWorld {
class MyState extends super.MyState {} // concrete
def foo {dynamics(new MyState)} // compiler error; ok
}
I would like to automatically weave the definition of a new function say introduced by an extending trait Ext into an abstract class A:
class Base {
abstract class A
class B extends A
case class C extends A
}
trait Ext extends Base {
trait A extends super.A {
def say = "hello"
}
}
object Test extends Base with Ext {
val b = new B
b.say
}
However, I obtain the following error:
<console>:12: error: value say is not a member of Test.B
b.say
Any way of doing it?
It seems you are trying to use virtual classes, which is a feature not available in Scala.
Once A and B are defined they can't be redefined (like method overriding).
abstract class A
class B extends A
On the other hand, given your example, your objective could be achieved by a simple mixin. Here it is with few rewrites:
class Base {
abstract class A
class B extends A
case class C extends A
}
trait Ext extends Base {
trait CanSay extends A {
def say = "hello"
}
}
object Test extends Base with Ext {
val b = new B with CanSay
def apply = b.say
}
Test.apply
No sure it will really help, but at least will help you understand what is going on.
Okay, as I said in a comment, it's not entirely clear what you're trying to do here, so I can't really try to suggest ways to do it. However, the approach you're using at the moment will not work.
Consider the class Hierarchy in this situation. At the base, we have A, which is then subclassed with B (in Base) and with Ext.A. These are not related save by their shared supertype, so you'll never find a say method on an instance of B.
The confusion possibly arises through the use of the word abstract. An abstract modifier on a class (even an inner class) does not make it an abstract member of the parent class, but denotes that it itself may have abstract members. There are ways of giving a class an abstract class member - through type parameters or type members. Unfortunately, you cannot derive from these AFAIK.