I have an abstract superclass with a variety of stateless implementations. It seems like the thing to do is make the abstract superclass a class, and make each implementation an object because I only ever need one of each.
This is a toy example, but it shows the compile error I’m getting:
// Tramsformer.scala
class Transformer {
def transform(value : String) : String
}
object Transformer {
getTransformer(String : name) : Transformer = {
name match {
case "upper" => UpperTransformer
// I'm getting "Cannot Resolve Symbol" on UpperTransformer,
// even though they're in the same package.
case _ => throw new IllegalArgumentException("...")
}
}
}
// ---
// UpperTransformer.scala is in the same package
object UpperTransformer extends Transformer {
override def transform(vlaue : String) = foo.toUpperCase()
}
I’m really shooting for some sort of dynamic dispatch on (dataProvider, desiredAction) here.
Then some class can call Transformer.getTransformer("upper").transform("stack-overflow") without making any unnecessary objects.
Any idea what I should be doing differently? Should I stop worrying about premature optimization and learn to love the instance?
The problem isn't visibility, it's that you simply do not define an object named UpperTransformer anywhere - only a class. If you replace class UpperTransformer with object UpperTransformer, your code should work fine.
Related
This question is somewhat hard to summarize. Following code block shows what I want to do.
I have a base class like this:
`class Base {
def methA:String="ook"
def methB:Int=1
}
Also I have a derived class, where I want each subclass method to call the super class method twice, compare the results and throw an exception on mismatch (this is for a test scenario).
But if I write
class Derived extends Base {
private def callDoublyAndCompare[T](fun:()=>T) : T = {
val fst=fun()
val snd=fun()
if(fst!=snd) throw new RuntimeException(s"Mismatch fst=$fst != snd=$snd")
snd
}
override def methB:Int={
callDoublyAndCompare(() => super[Derived].methB)
}
}
Then this will not compile. The only way out of this problem sofar has been to extract a method in class Derived which only calls the superclass' methB and to call this from the lambda call.
Is there a better way?
I understood you want to call super call method. Hope below is what you want.
You can call that as below with the key word super only
(new Derived).methB . This will call super call method in callDoublyAndCompare twice as per your code .
class Derived extends Base {
private def callDoublyAndCompare[T](fun:()=>T) : T = {
val fst=fun()
val snd=fun()
if(fst!=snd) throw new RuntimeException(s"Mismatch fst=$fst != snd=$snd")
snd
}
override def methB:Int={
callDoublyAndCompare(() => super.methB) //kept only super
}
}
The original example was not fully complete insofar as the Derived class was defined as inner class of another scala class.
After I moved out this inner class to the top level, the example from Praveen above suddenly worked.
I have a trait and case objects implementing it
trait Cowboy {
def code: String
}
object Cowboy {
case object Good extends Cowboy {
val code = "G"
}
case object Bad extends Cowboy {
val code = "B"
}
case object Ugly extends Cowboy {
val code = "U"
}
def fromString(code: String) = code match {
case Good.code => Good
case Bad.code => Bad
case Ugly.code => Ugly
}
}
I want to be able to serialize them. With the following serialization configs
serializers {
cowboySerializer = "mypackage.CowboySerializer"
}
serialization-bindings {
"mypackage.Cowboy" = cowboySerializer
}
I get this warning:
Multiple serializers found for class mypackage.Cowboy$Ugly$, choosing
first: Vector((interface
java.io.Serializable,akka.serialization.JavaSerializer#3fee36d8),
(interface
mypackage.Cowboy,brigadier.scraper.ScrapeStatusSerializer#10442350))
which means that java serializer is picked instead of mine.
If I disable java serializer via
akka.actor.serialization-bindings {
"java.io.Serializable" = none
}
the following error occurs:
Rejected to persist event type [mypackage.Cowboy$Ugly$] with sequence
number 1 for persistenceId [XXX] due to [mypackage.Cowboy$Ugly$
cannot be cast to mypackage.Cowboy]
This seems strange for me because casting
Cowboy.Ugly.asInstanceOf[Cowboy]
obviously works.
I also tried to map every case object to serializer as Akka docs says
If your messages are contained inside of a Scala object, then in order
to reference those messages, you will need use the fully qualified
Java class name. For a message named Message contained inside the
object named Wrapper you would need to reference it as Wrapper$Message
instead of Wrapper.Message.
serialization-bindings {
"mypackage.Cowboy$Good" = cowboySerializer
"mypackage.Cowboy$Bad" = cowboySerializer
"mypackage.Cowboy$Ugly" = cowboySerializer
}
and got ActorInitializationException caused by InvocationTargetException caused by ClassNotFoundException (can't find mypackage.Cowboy$Ugly class).
What am I doing wrong?
In Scala, it's possible to define class attributes in the constructor. But once you declare them there, it's not possible anymore to change the behavior (getters and setters), like you can when declaring in the class body?
Example:
class MyExample(var attribute : String)
{
def attribute() //trying to override getter <- doesn't work
}
class MyExample(theAttribute : String)
{
def attribute = theAttribute //overriding default accessor (was var)
}
If it's not possible, why is it so? It seems confusing when you show people that they can easily create attributes by setting var or val in constructor, and not care about getters and setters (they can change if they need), to ultimately find that, in fact, you should avoid using those kind of facilitations.
Let's for a moment imagine that it was possible to override the generated accessor-method:
class MyExample(var attribute : String)
{
def attribute() = attribute + "abc" // won't compile!
}
Without a further qualification it is impossible to tell whether the name attribute within method body refers to the class field or recursively to the method itself.
By design in Scala methods and fields belong to the same namespace, this, known as Uniform Access Principle, gives the ability to change an internal implementation without breaking the external interface.
An initial implementation could be:
class MyExample(val attribute : String)
Then changed onto:
class MyExample (attr :String) {
def attribute = attr toUpperCase
}
And then
class MyExample(var attribute : String)
Or
class MyExample(attr : String) {
def attribute = attr toUpperCase
def attribute_= (a : String) { attr = a + "abc" }
}
All without breaking any of the dependent code.
When field is defined as part of a constructor the automatically generated accessor-methods are syntactic sugar. The sugar eases quick prototyping and helps to keep the code concise. Nonetheless, whenever you want to add more substance you must use the full syntax.
I'm in the process of learning Scala for a new project having come from Rails. I've defined a type that is going to be used in a number of my models which can basically be thought of as collection of 'attributes'. It's basically just a wrapper for a hashmap that delegates most of its responsibilities to it:
case class Description(attributes: Map[String, String]) {
override def hashCode: Int = attributes.hashCode
override def equals(other: Any) = other match {
case that: Description => this.attributes == that.attributes
case _ => false
}
}
So I would then define a model class with a Description, something like:
case class Person(val name: String, val description: Description)
However, when I persist a Person with a SalatDAO I end up with a document that looks like this:
{
name : "Russell",
description:
{
attributes:
{
hair: "brown",
favourite_color: "blue"
}
}
}
When in actual fact I don't need the nesting of the attributes tag in the description tag - what I actually want is this:
{
name : "Russell",
description:
{
hair: "brown",
favourite_color: "blue"
}
}
I haven't tried, but I reckon I could get that to work if I made Description extend a Map rather than contain one, but I'd rather not, because a Description isn't a type of Map, it's something which has some of the behaviour of a Map as well as other behaviour of its own I'm going to add later. Composition over inheritance and so on.
So my question is, how can I tell Salat (or Casbah, I'm actually a bit unclear as to which is doing the conversion as I've only just started using them) how to serialize and deserialize the Description class? In the casbah tutorial here it says:
It is also possible to create your own custom type serializers and
deserializers. See Custom Serializers and Deserializers.
But this page doesn't seem to exist. Or am I going about it the wrong way? Is there actually a really simple way to indicate this is what I want to happen, an annotation or something? Or can I simply delegate the serialization to the attributes map in some way?
EDIT: After having a look at the source for the JodaTime conversion helper I've tried the following but have had no luck getting it to work yet:
import org.bson.{ BSON, Transformer }
import com.mongodb.casbah.commons.conversions.MongoConversionHelper
object RegisterCustomConversionHelpers extends Serializers
with Deserializers {
def apply() = {
super.register()
}
}
trait Serializers extends MongoConversionHelper
with DescriptionSerializer {
override def register() = {
super.register()
}
override def unregister() = {
super.unregister()
}
}
trait Deserializers extends MongoConversionHelper {
override def register() = {
super.register()
}
override def unregister() = {
super.unregister()
}
}
trait DescriptionSerializer extends MongoConversionHelper {
private val transformer = new Transformer {
def transform(o: AnyRef): AnyRef = o match {
case d: Description => d.attributes.asInstanceOf[AnyRef]
case _ => o
}
}
override def register() = {
BSON.addEncodingHook(classOf[Description], transformer)
super.register()
}
}
When I call RegisterCustomConversionHelpers() then save a Person I don't get any errors, it just has no effect, saving the document the same way as ever. This also seems like quite a lot to have to do for what I want.
Salat maintainer here.
I don't understand the value of Description as a wrapper here. It wraps a map of attributes, overrides the default equals and hashcode impl of a case class - which seems unnecessary since the impl is delegated to the map anyhow and that is exactly what the case class does anyway - and introduces an additional layer of indirection to the serialized object.
Have you considered just:
case class Person(val name: String, val description: Map[String, String])
This will do exactly what you want out of box.
In another situation I would recommend a simple type alias but unfortunately Salat can't support type aliases right now due to some issues with how they are depicted in pickled Scala signatures.
(You probably omitted this from your example from brevity, but it is best practice for your Mongo model to have an _id field - if you don't, the Mongo Java driver will supply one for you)
There is a working example of a custom BSON hook in the salat-core test package (it handles java.net.URL). It could be that your hook is not working simply because you are not registering it in the right place? But still, I would recommend getting rid of Description unless it is adding some value that is not evident from your example above.
Based on #prasinous' answer I decided this wasn't going to be that easy so I've changed my design a bit to the following, which pretty much gets me what I want. Rather than persisting the Description as a field I persist a vanilla map then mix in a Described trait to the model classes I want to have a description, which automatically converts the map to Description when the object is created. Would appreciate it if anyone can point out any obvious problems to this approach or any suggestions for improvement.
class Description(val attributes: Map[String, String]){
//rest of class omitted
}
trait Described {
val attributes: Map[String, String]
val description = new Description(attributes)
}
case class Person(name: String, attributes: Map[String, String]) extends Described
I know that objects are treated pretty much like singletons in scala. However, I have been unable to find an elegant way to specify default behavior on initial instantiation. I can accomplish this by just putting code into the body of the object declaration but this seems overly hacky. Using an apply doesn't really work because it can be called multiple times and doesn't really make sense for this use case.
Any ideas on how to do this?
Classes and objects both run the code in their body upon instantiation, by design. Why is this "hacky"? It's how the language is supposed to work. If you like extra braces, you can always use them (and they'll keep local variables from being preserved and world-viewable).
object Initialized {
// Initalization block
{
val someStrings = List("A","Be","Sea")
someStrings.filter(_.contains('e')).foreach(s => println("Contains e: " + s))
}
def doSomething { println("I was initialized before you saw this.") }
}
scala> Initialized.doSomething
Contains e: Be
Contains e: Sea
I was initialized before you saw this.
scala> Initialized.someStrings
<console>:9: error: value someStrings is not a member of object Initialized
Initialized.someStrings
Rex has it right, I just wanted to point out a pattern I use a lot, that saves you from having to use vars, while avoiding namespace pollution by intermediate values.
object Foo {
val somethingFooNeeds = {
val intermediate = expensiveCalculation
val something = transform(intermediate)
something
}
}
If it makes you feel better, you can create some class with protected constructor and object will create singleton of this class:
sealed class MyClass protected (val a: String, b: Int) {
def doStuff = a + b
}
object MyObject extends MyClass("Hello", b = 1)
Also notice, that sealed stops other classes and objects to extend MyClass and protected will not allow creation of other MyClass instances.
But I personally don't see any problems with some code in the body of the object. You can also create some method like init and just call it:
object MyObject {
init()
def init() {
...
}
}
The body of object and class declarations IS the default constructor and any code placed in there will be executed upon first reference, so that is exactly the way to do it.