case-class

问题 (NOTE: split from Shapeless: Trying to restrict HList elements by their type and Shapeless: own HList constraint using Coproduct ) Question 3 - restrict case classes by parameter types A very nice additional gain would be, if I could use HList constraints to constrain case class only to be built from AnyVals, Strings, and a specific MyBaseTrait, that recursively fulfill the same constraint. The constraint being defined on the base trait and not to have to touch any derived case class would be

问题 When I try to add a macro annotation to my case class: @macid case class CC[A: T](val x: A) I get the error: private[this] not allowed for case class parameters @macid is just the identity function, defined as a whitebox StaticAnnotation: import scala.language.experimental.macros import scala.reflect.macros.whitebox.Context import scala.annotation.StaticAnnotation class macid extends StaticAnnotation { def macroTransform(annottees: Any*): Any = macro macidMacro.impl } object macidMacro { def

问题 When I try to add a macro annotation to my case class: @macid case class CC[A: T](val x: A) I get the error: private[this] not allowed for case class parameters @macid is just the identity function, defined as a whitebox StaticAnnotation: import scala.language.experimental.macros import scala.reflect.macros.whitebox.Context import scala.annotation.StaticAnnotation class macid extends StaticAnnotation { def macroTransform(annottees: Any*): Any = macro macidMacro.impl } object macidMacro { def

问题 Is it ok, to create case classes with floating point fields, like: case class SomeClass(a:Double, b:Double) I guess auto generated equal method won't work in this case. Is overriding equals the best solution? EDIT: if overriding equals is the way to go, I would like to avoid hardcoding epsilon ( where epsilon is defined like => |this.a-a|< epsilon). This won't compile: case class SomeClass(a:Double, b:Double, implicit epsilon:Double) I am looking for a way to pass epsilon without passing

问题 I am trying to read a json file with the spark Dataset API, the problem is that this json contains spaces in some of the field names. This would be a json row {"Field Name" : "value"} My case class needs to be like this case class MyType(`Field Name`: String) Then I can load the file into a DataFrame and it will load the correct schema val dataframe = spark.read.json(path) The problem comes when I try to convert the DataFrame to a Dataset[MyType] dataframe.as[MyType] The StructSchema loaded

问题 I am trying to read a json file with the spark Dataset API, the problem is that this json contains spaces in some of the field names. This would be a json row {"Field Name" : "value"} My case class needs to be like this case class MyType(`Field Name`: String) Then I can load the file into a DataFrame and it will load the correct schema val dataframe = spark.read.json(path) The problem comes when I try to convert the DataFrame to a Dataset[MyType] dataframe.as[MyType] The StructSchema loaded

问题 If you're writing code that's using lots of beautiful, immutable data structures, case classes appear to be a godsend, giving you all of the following for free with just one keyword: Everything immutable by default Getters automatically defined Decent toString() implementation Compliant equals() and hashCode() Companion object with unapply() method for matching But what are the disadvantages of defining an immutable data structure as a case class? What restrictions does it place on the class

问题 Are there any best-practice guidelines on when to use case classes (or case objects) vs extending Enumeration in Scala? They seem to offer some of the same benefits. 回答1: One big difference is that Enumeration s come with support for instantiating them from some name String. For example: object Currency extends Enumeration { val GBP = Value("GBP") val EUR = Value("EUR") //etc. } Then you can do: val ccy = Currency.withName("EUR") This is useful when wishing to persist enumerations (for

问题 While reading akka docs right under messages and immutability section, It mentions about "explicitly exposing the state" inside case class. So my questions are; What is meant by saying "explicitly exposing the state" for case class? In order to achieve immutability, isn't it enough to write "case" for a class? Or I should be careful about its usage ? 回答1: What is meant by saying "explicitly exposing the state" for case class? The actor below represents its state with a mutable Set[Int] ,

问题 I have seen some of the other issues involving the infamous "22 fields/parameters" issue that is an inherent bug (feature?) of Scala V < 2.11. See here and here. However, as per this blog post, it appears that the 22 parameter limit in case class has been fixed; at least where the language is concerned. I have a case class that I want to load an arbitrary (Read: > 22) number of values into which will later be read into a JSON object using the Play library. It looks something like this: object