I never liked the new operator in Scala, particularly for DSLs. The workarounds for constructing objects without new are usually quite ugly. For instance, if you import scala.actors.Actor._, you have actor { ... }, but inside the body you are not having access to this: Actor, so there is all sorts of pseudo instance methods in that object, too, like receive, react, self, etc.
With Scala 2.10 macros, I wonder if there is a chance to get the following working?
object Button {
def apply(body: ? ): Button = macro applyImpl(body)
def applyImpl(c: Context)(body: c.Expr[ ? ]): c.Expr[Button] = ?
}
trait Button {
def text: String
def text_=(s: String): Unit
def doSomething(): Unit
}
Button {
text = "test"
doSomething()
}
As an additional challenge, what happens if doSomething is protected?
I don't think this will work, since
{
text = "test"
doSomething()
}
won't compile, as there is no text and no doSomething() method outside of the Button trait. Macros can currently only work on expressions that have already been typechecked.
Related
Imagine I have a service:
class ServiceA(serviceB: ServiceB) {
import Extractor._
def send(typeA: A) = serviceB.send(typeA.extract)
}
object Extractor {
implicit class Extractor(type: A) {
def extract = ???
}
}
I want the extract method to be an implicitly defined because it doesn't directly relate to A type/domain and is a solution specific adhoc extension.
Now I would like to write a very simple unit test that confirms that serviceB.send is called.
For that, I mock service and pass a mocked A to send. Then I could just assert that serviceB.send was called with the mocked A.
As seen in the example, the send method also does some transformation on typeA parameter so I would need to mock extract method to return my specified value. However, A doesn't have extract method - it comes from the implicit class.
So the question is - how do I mock out the implicit class as in the example above as imports are not first class citizens.
If you want to specify a bunch of customised extract methods, you can do something like this:
sealed trait Extractor[T] {
// or whatever signature you want
def extract(obj: T): String
}
object Extractor {
implicit case object IntExtractor extends Extractor[Int] {
def extract(obj: Int): String = s"I am an int and my value is $obj"
}
implicit case object StringExtractor extends Extractor[String] {
def extract(obj: String): String = s"I am "
}
def apply[A : Extractor](obj: A): String = {
implicitly[Extractor[A]].extract(obj)
}
}
So you have basically a sealed type family that's pre-materialised through case objects, which are arguably only useful in a match. But that would let you decouple everything.
If you don't want to mix this with Extractor, call them something else and follow the same approach, you can then mix it all in with a context bound.
Then you can use this with:
println(Extractor(5))
For testing, simply override the available implicits if you need to. A bit of work, but not impossible, you can simply control the scope and you can spy on whatever method calls you want.
e.g instead of import Extractor._ have some other object with test only logic where you can use mocks or an alternative implementation.
While scanning through dispatch code base, I noticed a method is defined like this:
def pack[T](req: { def abort() }, result: => T): HttpPackage[T]
The type annotation { def abort() } looks very strange to me. I thought it might be some thing similar to duck typing, so I tried to pass with some thing like object bar { def foo = print("Hello, world!") } but the compiler still complain type mismatched. I googled but couldn't find any article mention about it.
Does anyone know about this type annotation and its use cases?
Thanks in advance.
This defines a parameter req with a structural type i.e. a type defined by the existence of certain members. In this case any type with an abort() method. You can't pass bar since it does not have such a method. If you defined it as:
object Bar {
def abort(): Unit = print("Aborting!")
}
then you can pass it to pack:
pack(Bar, { ... })
This is known as structural typing in the Scala world, or more colloquially, as duck typing. From the linked article:
def quacker(duck: {def quack(value: String): String}) {
println (duck.quack("Quack"))
}
object BigDuck {
def quack(value: String) = {
value.toUpperCase
}
}
quacker(BigDuck)
so your method above will accept any object that defines an abort() method, without implementing a specific interface/trait.
This is particularly useful for handling sets of classes that implement the same methods without a common interface/trait, and that you can't retrofit an interface over (e.g. from legacy apps/libraries)
I am trying to learn scala. I know how to write a function. This is how I write a function.
def test_function: Unit = {
println("This is just a test")
}
But then I started learning playframework. This is how they write a function in controller in play.
def test_function: Unit = Action{
println("This is just a test")
}
My question is what is this Action doing before the curly braces? What is it called? How can I write my own? I hope I have made my question clear. Thanks in advance.
You can get this kind of behavior by defining an apply method on an object called Action:
object Action {
def apply(block: => Unit): Unit = {
println("before")
block // do the action in the block
println("after")
}
}
Then both of these:
Action { println("hi") }
Action(println("hi"))
Produce this:
before
hi
after
The thing in braces after Action is just the argument to the apply method. Scala allows either parentheses or braces, but using braces allows you to put multiple statements in:
Action {
println("a")
println("b")
}
yields:
before
a
b
after
Action is a trait (play.api.mvc.Action). Essentially it represents this type: play.api.mvc.Request => play.api.mvc.Result (doc1, doc2).
In your case you are using Action {...} which is equivalent to Action(...) and converted by compiler to Action.apply(...) call. If you check source code you'll see the apply method signatures defined not only on the Action trait and it's companion object, but also in here:
/**
* Provides helpers for creating `Action` values.
*/
trait ActionBuilder[+R[_]] extends ActionFunction[Request, R]
In your case you are not taking any request and not producing any response, so essentially your Action is a function call of a form apply(block: => Result) where Result is thrown away since you define return type of your function as Unit.
Action supports many ways you can handle its body (including Futures) so pick the right apply method to cover your needs.
You can extend Action if you need to since it's not a final implementation. Here is an example:
case class Logging[A](action: Action[A]) extends Action[A]
Action is basically a function alias of the shape play.api.mvc.Request => play.api.mvc.Result. When you see Action { }, you are actually seeing apply function of the companion object of that type and are passing a body that should provide that Request => Result function.
The companion object has roughly the shape of:
object Action {
def apply(f: Request => Response): Action = ...
}
so that when you call Action { ... }, the { ... } is that function that will be executed when the action is invoked.
In your example, println("This is just a test") serves as the provider of the Result.
The question is self explanatory, but please allow me to provide an example:
I have the following:
class Foo {
def doAndPrint {
val result = doSomething()
val msg = message(result)
println(msg)
}
private def message(result: Result): String = {
"message formatted with %s".format(result)
}
}
In this context, the question is: Should def message(result: Result) live in object Foo?
The argument in favor is making explicit that def message(result: Result) does not depends on any state within class Foo.
The argument against is that the motivation of companion objects was to provide a place to put java public static methods.
The answer to this false dichotomy is neither. It should be a local method to doAndPrint.
class Foo {
def doAndPrint {
val result = doSomething()
def message(result: Result): String = s"message formatted with $result"
val msg = message(result)
println(msg)
}
}
In fact,
class Foo {
def doAndPrint {
val result = doSomething()
def message = s"message formatted with $result"
println(message)
}
}
Notice that it really depends on local state.
Edit: OK, as a nod to "self-explanatory," I would add, use the smallest scope that makes sense, and the example points out an asymmetry in the private relations between companions. Which begs for many puns which I haven't time to supply.
Answering more directly, from my observations, the companion module does not normally serve as a repository for FooUtil-style functions, though it does serve as a repository for implicit conversions, which have an arguably similar flavor, albeit public. Consider what winds up in the objects of collection types.
Consider a separation of concerns:
class Foo(f: String => Unit) {
def doSomethingAndDoSomethingWithIt {
val result = doSomething()
def message = s"message formatted with $result"
f(message)
}
}
You should put the methods where they belong. If you need to break things up for testing purposes, readability or even maintainability then you need to break them up. Even though Scala is influenced by FP concepts, FP patterns, and an FP mindset, it is still also an OO language.
Private helper methods are just that, helper methods to make your code easier to work with. If your class needs them, then there is no reason to spread out that logic in another class... just 'cause. Put them in the same place (and add in some means to access those methods for unit testing purposes like package visibility.)
Consider the following typical Scala 'pimp' code:
class PimpedA(a:A){
def pimp() = "hi"
}
implicit def pimpA(a:A) = new PimpedA(a)
new A(){
pimp() //<--- does not compile
}
However, changing it to:
new A(){
this.pimp()
}
Makes it work.
Shouldn't it be the same to the Scala compiler?
EDIT : Is there any solution that can make it work without having to add the this.?
Not at all. For it to work, pimp needs to be either an object or an imported member of a value, and it is neither. A class has an "implicit" import this._. It has not a mechanism that auto-prepends this to stuff to see if it compiles.
In this case you should give compiler a hint that pimp() is not a random function. When you write
this.pimp()
compiler know there isn't pimp function on class A so it's an error and before giving up it searches implicit conversion in scope and finds it.
pimpA(this).pimp()
And when you just call pimp() compiler doesn't know what object to pass to the pimpA(a: A) implicit function.
UPDATE
It is hard to understand what is your goal. I can only suggest to make PimpedA a typeclass (Pimp[T] in this example).
trait Pimp[T] {
def action(p: T): String
}
implicit object PimpA extends Pimp[A] {
override def action(p: A) = "some actions related to A"
}
def pimp[T: Pimp](p: T) = implicitly[Pimp[T]].action(p)
class A {
val foo = pimp(this)
}
scala> new A foo
res2: String = some actions related to A