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.)
Related
I want to store a state (key -> value) in scala using functional way. I probably learned while ago in Odersky class but can not remember any more.
Here's my non-functional approach;
import org.scalatest.{FunSuite, Matchers}
trait EventHandler
class StatefulNonFn {
type EventName = String
private var state = Map.empty[EventName, EventHandler]
def update(name: String): EventHandler = {
state.get(name).fold {
val handler = new EventHandler {}
state += name -> handler
handler
}(eh => eh)
}
}
class NonFunctionalStateSpec extends FunSuite with Matchers {
test("stateful") {
val stateResult = new StatefulNonFn().update("MusicAdded")
stateResult.isInstanceOf[EventHandler] shouldBe true
}
}
One attempt I made is to make the state a "function of EventName and previousState" which makes sense but now I can't figure out how do I store those all states?
My first call is going to be fine because the state is empty in that case.
import org.scalatest.{FunSuite, Matchers}
trait EventHandler
class Stateful {
type EventName = String
private val stateFn = new ((String, Map[EventName, EventHandler]) => Map[EventName, EventHandler]) {
override def apply(name: String, prevState: Map[EventName, EventHandler]): Map[EventName, EventHandler] = {
val handler = new EventHandler {}
prevState + (name -> handler)
}
}
def initState = Map.empty[EventName, EventHandler]
def update(name: String, prevState: Map[EventName, EventHandler]) = stateFn(name, prevState)
}
class FunctionalStateSpec extends FunSuite with Matchers {
test("stateful") {
val stateHelper = new Stateful()
val stateResult = stateHelper.update("MusicAdded", stateHelper.initState)
stateResult.keys.size shouldBe 1
val stateResult1 = stateHelper.update("MusicDeleted", stateResult)
stateResult1.keys.size shouldBe 2
//what i obviously want is something like this without me wanting to store the previousStates
//stateHelper.update("MusicAdded1")
//stateHelper.update("MusicAdded2")
}
}
I am not sure, maybe something eventually has to be mutable. How do I Store the previous states in above case? without the client being the one to supply it in each call. Because state can be updated from 5 separate clients without knowing the previous state.
It just turns out that if you want to do some useful program, you need mutations and you need state. You need to do IO, like saving into the database (which could return some different ID every time you do it), or getting a random number, or the current timestamp, or printing into console, etc.
If you are doing functional programming, is not about doing pure, deterministic, total stuff. It's about isolating sideffects (like mutations and state) away.
So strictly pure languages like Haskell do it by returning actions (or plans, or descriptions of actions...) instead of performing them. The runtime performs those actions, so that way you have two things:
Your pure and sexy program
The runtime, in charge of doing the dirty stuff.
However Scala doesn't just expects you to return actions so that the runtime executes them... You need to do it yourself.
That being said, your solution is perfectly ok, if you don't want to go to dark places. Otherwise, I'd recommend you to read this, an article from John Degoes that basically explains how to do what you want (by simultaneously defining what a freemonad is).
I see some Scala code like this:
case class Team(private val members: List[User]) {
def removed(member: User): Team = {
Team(members.filterNot(_ == member))
}
def added(member: User): Team = {
Team(member :: members)
}
def allNames: List[String] = members.map(_.name)
}
You can see the Team is a case class, but it has a private field members. And in the body, it has several methods to construct a new Team, and a method allNames which export some information of the private members.
I'm not sure if the usage of case class is good, since I think a case class is a data class, we should not use private fields. For this case, I think a normal class is enough:
class Team(members: List[User]) {
def removed(member: User): Team = {
new Team(members.filterNot(_ == member))
}
def added(member: User): Team = {
new Team(member :: members)
}
def allNames: List[String] = members.map(_.name)
}
You can see I removed the case, and also private since for a normal class, the fields of constructor is private by default.
But I'm not sure if there is any good reason to write the code in the first approache.
Private vals in case classes are a little surprising because they're not as private as you might imagine if you think other ways of getting that value are just syntactic sugar.
In particular, pattern matching will give you the underlying value:
whatever match {
case Team(members) => println("I can see "+members.mkString)
}
And the value still plays a role in equality (even if you can't get it by name), and you can create copies with different values using copy.
Sometimes a private val is used to enforce best practices for that class, which is to only use pattern matching to get the values (e.g. because you will often want to pattern match other things, and this enforces consistency). Sometimes it's an indication that the programmer doesn't understand how it works and thinks its enforcing a complete lack of access to the val.
Very many times, I'll want to "replace" a single method of a given object.
foo: Foo
foo.bar(i) // original
foo.baz(s) // replace this implementation
I'll wind up creating a pass-through wrapper class.
class FooWrapper(foo: Foo) extends Foo {
def bar(i: Int) = foo.bar(i)
def baz(s: String) = foo.baz(s)
}
And then
foo: Foo
val foo2 = new FooWrapper(foo) { def baz(s: String) = ... }
foo2.bar(i)
foo2.baz(s)
This works with traits and classes, and works without modifying the source code of the type.
I use this quite a bit, particularly when adapting libraries or other bits of code.
This can get tedious with lots of methods. The other day, I wanted to replace the shutdown method on an ExecutorService instance, and I had to do this for a dozen methods.
Is this a common idiom, or is this normally done another way? I suspect this could be done nicely with a macro, though I haven't found any existing ones that do this.
You can achieve that with AOP (Aspect-oriented programming)
There're many libraries to do so, try this one -
https://github.com/adamw/scala-macro-aop
Note that this library is in POC stage for now so you might look for something more mature. I've put it here because I think it shows the concept very clearly.
For your example you'll have to do something like
class FooWrapper(#delegate wrapped: Foo) extends Foo {
def baz(i: Int) = ???
}
In Scala, a val can override a def, but a def cannot override a val.
So, is there an advantage to declaring a trait e.g. like this:
trait Resource {
val id: String
}
rather than this?
trait Resource {
def id: String
}
The follow-up question is: how does the compiler treat calling vals and defs differently in practice and what kind of optimizations does it actually do with vals? The compiler insists on the fact that vals are stable — what does in mean in practice for the compiler? Suppose the subclass is actually implementing id with a val. Is there a penalty for having it specified as a def in the trait?
If my code itself does not require stability of the id member, can it be considered good practice to always use defs in these cases and to switch to vals only when a performance bottleneck has been identified here — however unlikely this may be?
Short answer:
As far as I can tell, the values are always accessed through the accessor method. Using def defines a simple method, which returns the value. Using val defines a private [*] final field, with an accessor method. So in terms of access, there is very little difference between the two. The difference is conceptual, def gets reevaluated each time, and val is only evaluated once. This can obviously have an impact on performance.
[*] Java private
Long answer:
Let's take the following example:
trait ResourceDef {
def id: String = "5"
}
trait ResourceVal {
val id: String = "5"
}
The ResourceDef & ResourceVal produce the same code, ignoring initializers:
public interface ResourceVal extends ScalaObject {
volatile void foo$ResourceVal$_setter_$id_$eq(String s);
String id();
}
public interface ResourceDef extends ScalaObject {
String id();
}
For the subsidiary classes produced (which contain the implementation of the methods), the ResourceDef produces is as you would expect, noting that the method is static:
public abstract class ResourceDef$class {
public static String id(ResourceDef $this) {
return "5";
}
public static void $init$(ResourceDef resourcedef) {}
}
and for the val, we simply call the initialiser in the containing class
public abstract class ResourceVal$class {
public static void $init$(ResourceVal $this) {
$this.foo$ResourceVal$_setter_$id_$eq("5");
}
}
When we start extending:
class ResourceDefClass extends ResourceDef {
override def id: String = "6"
}
class ResourceValClass extends ResourceVal {
override val id: String = "6"
def foobar() = id
}
class ResourceNoneClass extends ResourceDef
Where we override, we get a method in the class which just does what you expect. The def is simple method:
public class ResourceDefClass implements ResourceDef, ScalaObject {
public String id() {
return "6";
}
}
and the val defines a private field and accessor method:
public class ResourceValClass implements ResourceVal, ScalaObject {
public String id() {
return id;
}
private final String id = "6";
public String foobar() {
return id();
}
}
Note that even foobar() doesn't use the field id, but uses the accessor method.
And finally, if we don't override, then we get a method which calls the static method in the trait auxiliary class:
public class ResourceNoneClass implements ResourceDef, ScalaObject {
public volatile String id() {
return ResourceDef$class.id(this);
}
}
I've cut out the constructors in these examples.
So, the accessor method is always used. I assume this is to avoid complications when extending multiple traits which could implement the same methods. It gets complicated really quickly.
Even longer answer:
Josh Suereth did a very interesting talk on Binary Resilience at Scala Days 2012, which covers the background to this question. The abstract for this is:
This talk focuses on binary compatibility on the JVM and what it means
to be binary compatible. An outline of the machinations of binary
incompatibility in Scala are described in depth, followed by a set of rules and guidelines that will help developers ensure their own
library releases are both binary compatible and binary resilient.
In particular, this talk looks at:
Traits and binary compatibility
Java Serialization and anonymous classes
The hidden creations of lazy vals
Developing code that is binary resilient
The difference is mainly that you can implement/override a def with a val but not the other way around. Moreover val are evaluated only once and def are evaluated every time they are used, using def in the abstract definition will give the code who mixes the trait more freedom about how to handle and/or optimize the implementation. So my point is use defs whenever there isn't a clear good reason to force a val.
A val expression is evaluated once on variable declaration, it is strict and immutable.
A def is re-evaluated each time you call it
def is evaluated by name and val by value. This means more or less that val must always return an actual value, while def is more like a promess that you can get a value when evaluating it. For example, if you have a function
def trace(s: => String ) { if (level == "trace") println s } // note the => in parameter definition
that logs an event only if the log level is set to trace and you want to log an objects toString. If you have overriden toString with a value, then you need to pass that value to the trace function. If toString however is a def, it will only be evaluated once it's sure that the log level is trace, which could save you some overhead.
def gives you more flexibility, while val is potentially faster
Compilerwise, traits are compiled to java interfaces so when defining a member on a trait, it makes no difference if its a var or def. The difference in performance would depend on how you choose to implement it.
Assume I want to offer method foo on existing type A outside of my control. As far as I know, the canonical way to do this in Scala is implementing an implicit conversion from A to some type that implements foo. Now I basically see two options.
Define a separate, maybe even hidden class for the purpose:
protected class Fooable(a : A) {
def foo(...) = { ... }
}
implicit def a2fooable(a : A) = new Fooable(a)
Define an anonymous class inline:
implicit def a2fooable(a : A) = new { def foo(...) = { ... } }
Variant 2) is certainly less boilerplate, especially when lots of type parameters happen. On the other hand, I think it should create more overhead since (conceptually) one class per conversion is created, as opposed to one class globally in 1).
Is there a general guideline? Is there no difference, because compiler/VM get rid of the overhead of 2)?
Using a separate class is better for performance, as the alternative uses reflection.
Consider that
new { def foo(...) = { ... } }
is really
new AnyRef { def foo(...) = { ... } }
Now, AnyRef doesn't have a method foo. In Scala, this type is actually AnyRef { def foo(...): ... }, which, if you remove AnyRef, you should recognize as a structural type.
At compile time, this time can be passed back and forth, and everywhere it will be known that the method foo is callable. However, there's no structural type in the JVM, and to add an interface would require a proxy object, which would cause some problems such as breaking referential equality (ie, an object would not be equal with a structural type version of itself).
The way found around that was to use cached reflection calls for structural types.
So, if you want to use the Pimp My Library pattern for any performance-sensitive application, declare a class.
I believe 1 and 2 get compiled to the same bytecode (except for the class name that gets generated in case 2).
If Fooable exists only for you to be able to convert implicitly A to Fooable (and you're never going to directly create and use a Fooable), then I would go with option 2.
However, if you control A (meaning A is not a java library class that you can't subclass) I would consider using a trait instead of implicit conversions to add behaviour to A.
UPDATE:
I have to reconsider my answer. I would use variant 1 of your code, because variant 2 turns out to be using reflection (scala 2.8.1 on Linux).
I compiled these two versions of the same code, decompiled them to java with jd-gui and here are the results:
source code with named class
class NamedClass { def Foo : String = "foo" }
object test {
implicit def StrToFooable(a: String) = new NamedClass
def main(args: Array[String]) { println("bar".Foo) }
}
source code with anonymous class
object test {
implicit def StrToFooable(a: String) = new { def Foo : String = "foo" }
def main(args: Array[String]) { println("bar".Foo) }
}
compiled and decompiled to java with java-gui. The "named" version generates a NamedClass.class that gets decompiled to this java:
public class NamedClass
implements ScalaObject
{
public String Foo()
{
return "foo";
}
}
the anonymous generates a test$$anon$1 class that gets decompiled to the following java
public final class test$$anon$1
{
public String Foo()
{
return "foo";
}
}
so almost identical, except for the anonymous being "final" (they apparently want to make extra sure you won't get out of your way to try and subclass an anonymous class...)
however at the call site I get this java for the "named" version
public void main(String[] args)
{
Predef..MODULE$.println(StrToFooable("bar").Foo());
}
and this for the anonymous
public void main(String[] args) {
Object qual1 = StrToFooable("bar"); Object exceptionResult1 = null;
try {
exceptionResult1 = reflMethod$Method1(qual1.getClass()).invoke(qual1, new Object[0]);
Predef..MODULE$.println((String)exceptionResult1);
return;
} catch (InvocationTargetException localInvocationTargetException) {
throw localInvocationTargetException.getCause();
}
}
I googled a little and found that others have reported the same thing but I haven't found any more insight as to why this is the case.