Say I have:
import org.scalatest.ShouldMatchers._;
This brings a few implicit conversions into scope.
How can I alias them in a package object so that I can bring the implicits into scope with:
import code.ThePackageObject._;
Apparently the ShouldMatchers object extends the ShouldMatchers trait (where the actual definition of the implicits are done). This is a common idiom that allows to simply mix the trait where you need it. So you can simply mix ShouldMatchers (the trait) in your package object:
package object ThePackageObject extends ShouldMatchers
Related
From what I've read, Scala sealed traits can be used for ENUM like behavior, but they are not as intuitive to use in Java or Kotlin.
Scala code (and Suzy MV)
package com.example
sealed trait Answer
case object Yes extends Answer
case object No extends Answer
case object Maybe extends Answer
Java code to call above Scala
import com.example.Yes$;
Yes$ myAnswer = Yes$.MODULE$;
How do you call this in Kotlin?
Backticks are your friends here!
Kotlin
import com.example.`Yes$`
`Yes$`.`MODULE$`
Inside the Scala standard library, I noticed this:
package scala
package collection
package mutable
import generic._
...
/** Explicit instantiation of the `Seq` trait to reduce class file size in subclasses. */
abstract class AbstractSeq[A] extends scala.collection.AbstractSeq[A] with Seq[A]
AbstractSeq[A] extends AbstractSeq[A] with Seq[A]?
What is going on here?
It is extending scala.collection.AbstractSeq, while the definition is of scala.collection.mutable.AbstractSeq, so those are different classes. (Note the different package names: scala.collection vs. scala.collection.mutable.)
They are different classes. The one you are looking at is scala.collection.mutable.AbstractSeq, the one it is extending is scala.collection.AbstractSeq.
Package is a kind of namespace. Different classes can have the same name as long as they are in different packages.
I would like to create a macro generated hierarchy of sealed abstract and case classes. There was an example similar to this with http://docs.scala-lang.org/overviews/macros/typemacros.html but is is now obsolete. Is this still possible?
I think it would be incredibly powerful to generate a type safe AST for some specified grammar. Ideally with an IDE able to resolve all the classes.
First for some shameless self-promotion: Eugene Burmako and I are giving a talk on type providers, a closely related topic, at Scalar 2014 tomorrow, and I encourage you to take a look at the example project we put together for the talk if you're interested in this kind of thing.
While type macros are no longer supported, you can accomplish essentially the same thing with macro annotations from macro paradise (which is available as a plugin for Scala 2.10 and 2.11):
import scala.annotation.StaticAnnotation
import scala.language.experimental.macros
import scala.reflect.macros.Context
// Add constructor arguments here.
class expand extends StaticAnnotation {
def macroTransform(annottees: Any*) = macro Expander.expand_impl
}
object Expander {
def expand_impl(c: Context)(annottees: c.Expr[Any]*) = {
import c.universe._
annottees.map(_.tree) match {
case List(q"trait $name") => c.Expr[Any](
// Add your own logic here, possibly using arguments on the annotation.
q"""
sealed trait $name
case class Foo(i: Int) extends $name
case class Bar(s: String) extends $name
case object Baz extends $name
"""
)
// Add validation and error handling here.
}
}
}
And then:
scala> #expand trait MyADT
defined trait MyADT
defined class Foo
defined class Bar
defined module Baz
You can add arguments to the annotation that will be available at compile time, allowing you to parse an external resource that you can use to generate the implementation of the ADT, for example.
Macro annotations are very experimental and their status is still up in the air—there's no guarantee that they'll ship with Scala 2.12, for example. Something similar (although not quite so clean) is possible using plain old def macros and structural types—see the example project linked above for more detail and some demonstrations. In any case, this kind of mechanism is of interest to many people, including the developers of Scala's macro system, so even if macro annotations disappear at some point down the road, there's likely to be some way to accomplish what you've described here.
When i run base example for testing actors:
class MySpec(_system: ActorSystem) extends TestKit(_system) with ImplicitSender
with WordSpec with MustMatchers with BeforeAndAfterAll {
I got error:
class WordSpec needs to be a trait to be mixed in
what am I doing wrong?
In ScalaTest 2.0 you can find both class and trait for WordSpec. The class named WordSpec and trait is WordSpecLike. So just use WordSpecLike instead of WordSpec:
class MySpec(_system: ActorSystem) extends TestKit(_system) with ImplicitSender
with WordSpecLike with MustMatchers with BeforeAndAfterAll {
In addition to what 1esha proposed, there's one more solution in akka documentation
If for some reason it is a problem to inherit from TestKit due to it being a concrete class instead of a trait, there’s TestKitBase:
import akka.testkit.TestKitBase
class MyTest extends TestKitBase {
implicit lazy val system = ActorSystem()
// put your test code here ...
shutdown(system)
}
The implicit lazy val system must be declared exactly like that (you can of course pass arguments to the actor system factory as needed) because trait TestKitBase needs the system during its construction.
As of Scalatest 2.0, the Specs you mix in are now classes not traits. Which means you can't use them with Akka's test kit... both are classes and you can only extend one of them.
Switch to scalatest 1.9.1. It's still supported by them and is the last version that released before they made that change and broke things for akka users. In 1.9.1, the specs are still traits.
What is the "correct" way to alias an object in Scala?
For example, let's say I need a RoleGroup in scope in various parts of my application (which is broken up into SBT sub projects)
trait RoleGroup
object RoleGroup {
case object ADMIN extends RoleGroup
case object MEMBER extends RoleGroup
case object PUBLIC extends RoleGroup
}
Since I don't want to repeatedly import RoleGroup, I decided to alias RoleGroup trait and object into type and val counterparts like so:
package com.developer
package controller
trait ControllerBase {
type RoleGroup = controller.RoleGroup
val RoleGroup = controller.RoleGroup
...
}
and then sub project package objects can extend the helper trait to get the imports for free:
package com.client
package object member
extends com.developer.controller.ControllerBase
Am doing the same for other case objects that need to be in scope. Is this a sensible solution? i.e. are there any drawbacks/issues I need to be aware of? Everything compiles and browser test pages appear to run just as in pre-refactored application, but am not sure if this is the best approach.
It's a sensible approach. In fact it's being applied in the Scala library itself.
There are just two imaginable levels of members you need to alias: type (i.e. traits and classes) and value (i.e. objects, packages and values). You cover them both.