Say I have a Student class which has lots of actions:
final case class Student(name: String, knowledge: List[String]) {
def learn(item: String) : Student = this.copy(knowledge = knowledge :+ item)
}
Here you can notice that this class is not influenced by any outer State.
But if I put this class into a Stateful environment(like a School):
final case class School(students: Map[String, Student]) {
def learn(studentName: String, item: String) : State[School, Student] = State {
oldSchool => {
val oldStudent = students.get(studentName).getOrElse(Student(studentName, List()))
val newStudent = oldStudent.learn(item)
oldSchool.copy(students = students + (studentName -> newStudent)) -> newStudent
}
}
}
And then I cannot use student.learn(info) directly, for Student even doesn't know the environment(School class) exists. So if I want to call the actions of a student, I have to call the proxy function exposed by the Environment class. If I have lots of actions in Student, I HAVE TO write the same count of proxy functions in School, which is frustrating and not fun at all.
Any advices? How to manage this kind of State hierarchy?
Inspired by #WillemVanOnsem, here is my solution.
def updateStudent: String => (Student => Student) => School =
name =>
func =>
this.copy(
students = students + (name -> func(
students.get(name).getOrElse(Student(name, List()))
))
)
And the usage likes:
val stu1 = Student("name1", List())
val school = School(Map(stu1.name -> stu1))
val newSchool = school.updateStudent("name1") { student =>
student.learn("someItem")
}
And I notice that if your hierarchy is really deep, the (Student => Student) part can be replaced by Lens, so the you should prepare a bunch of Lens, rather than a bunch of Proxy Functions of different depth of functions, cool!
Related
My use case has case classes something like
case class Address(name:String,pincode:String){
override def toString =name +"=" +pincode
}
case class Department(name:String){
override def toString =name
}
case class emp(address:Address,department:Department)
I want to create a DSL like below.Can anyone share the links about how to create a DSL and any suggestions to achieve the below.
emp.withAddress("abc","12222").withDepartment("HR")
Update:
Actual use case class may have more fields close to 20. I want to avoid redudancy of code
I created a DSL using reflection so that we don't need to add every field to it.
Disclamer: This DSL is extremely weakly typed and I did it just for fun. I don't really think this is a good approach in Scala.
scala> create an Employee where "homeAddress" is Address("a", "b") and "department" is Department("c") and that_s it
res0: Employee = Employee(a=b,null,c)
scala> create an Employee where "workAddress" is Address("w", "x") and "homeAddress" is Address("y", "z") and that_s it
res1: Employee = Employee(y=z,w=x,null)
scala> create a Customer where "address" is Address("a", "b") and "age" is 900 and that_s it
res0: Customer = Customer(a=b,900)
The last example is the equivalent of writing:
create.a(Customer).where("address").is(Address("a", "b")).and("age").is(900).and(that_s).it
A way of writing DSLs in Scala and avoid parentheses and the dot is by following this pattern:
object.method(parameter).method(parameter)...
Here is the source:
// DSL
object create {
def an(t: Employee.type) = new ModelDSL(Employee(null, null, null))
def a(t: Customer.type) = new ModelDSL(Customer(null, 0))
}
object that_s
class ModelDSL[T](model: T) {
def where(field: String): ValueDSL[ModelDSL2[T], Any] = new ValueDSL(value => {
val f = model.getClass.getDeclaredField(field)
f.setAccessible(true)
f.set(model, value)
new ModelDSL2[T](model)
})
def and(t: that_s.type) = new { def it = model }
}
class ModelDSL2[T](model: T) {
def and(field: String) = new ModelDSL(model).where(field)
def and(t: that_s.type) = new { def it = model }
}
class ValueDSL[T, V](callback: V => T) {
def is(value: V): T = callback(value)
}
// Models
case class Employee(homeAddress: Address, workAddress: Address, department: Department)
case class Customer(address: Address, age: Int)
case class Address(name: String, pincode: String) {
override def toString = name + "=" + pincode
}
case class Department(name: String) {
override def toString = name
}
I really don't think you need the builder pattern in Scala. Just give your case class reasonable defaults and use the copy method.
i.e.:
employee.copy(address = Address("abc","12222"),
department = Department("HR"))
You could also use an immutable builder:
case class EmployeeBuilder(address:Address = Address("", ""),department:Department = Department("")) {
def build = emp(address, department)
def withAddress(address: Address) = copy(address = address)
def withDepartment(department: Department) = copy(department = department)
}
object EmployeeBuilder {
def withAddress(address: Address) = EmployeeBuilder().copy(address = address)
def withDepartment(department: Department) = EmployeeBuilder().copy(department = department)
}
You could do
object emp {
def builder = new Builder(None, None)
case class Builder(address: Option[Address], department: Option[Department]) {
def withDepartment(name:String) = {
val dept = Department(name)
this.copy(department = Some(dept))
}
def withAddress(name:String, pincode:String) = {
val addr = Address(name, pincode)
this.copy(address = Some(addr))
}
def build = (address, department) match {
case (Some(a), Some(d)) => new emp(a, d)
case (None, _) => throw new IllegalStateException("Address not provided")
case _ => throw new IllegalStateException("Department not provided")
}
}
}
and use it as emp.builder.withAddress("abc","12222").withDepartment("HR").build().
You don't need optional fields, copy, or the builder pattern (exactly), if you are willing to have the build always take the arguments in a particular order:
case class emp(address:Address,department:Department, id: Long)
object emp {
def withAddress(name: String, pincode: String): WithDepartment =
new WithDepartment(Address(name, pincode))
final class WithDepartment(private val address: Address)
extends AnyVal {
def withDepartment(name: String): WithId =
new WithId(address, Department(name))
}
final class WithId(address: Address, department: Department) {
def withId(id: Long): emp = emp(address, department, id)
}
}
emp.withAddress("abc","12222").withDepartment("HR").withId(1)
The idea here is that each emp parameter gets its own class which provides a method to get you to the next class, until the final one gives you an emp object. It's like currying but at the type level. As you can see I've added an extra parameter just as an example of how to extend the pattern past the first two parameters.
The nice thing about this approach is that, even if you're part-way through the build, the type you have so far will guide you to the next step. So if you have a WithDepartment so far, you know that the next argument you need to supply is a department name.
If you want to avoid modifying the origin classes you can use implicit class, e.g.
implicit class EmpExtensions(emp: emp) {
def withAddress(name: String, pincode: String) {
//code omitted
}
// code omitted
}
then import EmpExtensions wherever you need these methods
For my project, I would like to make a tree model; let's say it's about files and directories. But files can be in multiple directories at the same time, so more like the same way you add tags to email in gmail.
I want to build a model for competences (say java, scala, angular, etc) and put them in categories. In this case java and scala are languages, agila and scrum are ways of working, angular is a framework / toolkit and so forth. But then we want to group stuff flexibly, ie play, java and scala are in a 'backend' category and angular, jquery, etc are in a frontend category.
I figured I would have a table competences like so:
case class Competence (name: String, categories: Option[Category])
and the categories as follows:
case class Category ( name: String, parent: Option[Category] )
This will compile, but SORM will generate an error (from activator console):
scala> import models.DB
import models.DB
scala> import models.Category
import models.Category
scala> import models.Competence
import models.Competence
scala> val cat1 = new Category ( "A", None )
cat1: models.Category = Category(A,None)
scala> val sav1 = DB.save ( cat1 )
sorm.Instance$ValidationException: Entity 'models.Category' recurses at 'models.Category'
at sorm.Instance$Initialization$$anonfun$2.apply(Instance.scala:216)
at sorm.Instance$Initialization$$anonfun$2.apply(Instance.scala:216)
at scala.Option.map(Option.scala:146)
at sorm.Instance$Initialization.<init>(Instance.scala:216)
at sorm.Instance.<init>(Instance.scala:38)
at models.DB$.<init>(DB.scala:5)
at models.DB$.<clinit>(DB.scala)
... 42 elided
Although I want the beautiful simplicity of sorm, will I need to switch to Slick for my project to implement this? I had the idea that link tables would be implicitly generated by sorm. Or could I simply work around the problem by making a:
case class Taxonomy ( child: Category, parent: Category )
and then do parsing / formatting work on the JS side? It seems to make the simplicity of using sorm disappear somewhat.
To give some idea, what I want is to make a ajaxy page where a user can add new competences in a list on the left, and then link/unlink them to whatever category tag in the tree he likes.
I encountered the same question. I needed to define an interation between two operant, which can be chained(recursive). Like:
case class InteractionModel(
val leftOperantId: Int,
val operation: String ,
val rightOperantId: Int,
val next: InteractionModel)
My working around: change this case class into Json(String) and persist it as String, when retreiving it, convert it from Json. And since it's String, do not register it as sorm Entity.
import spray.json._
case class InteractionModel(
val leftOperantId: Int,
val operation: String ,
val rightOperantId: Int,
val next: InteractionModel) extends Jsonable {
def toJSON: String = {
val js = this.toJson(InteractionModel.MyJsonProtocol.ImJsonFormat)
js.compactPrint
}
}
//define protocol
object InteractionModel {
def fromJSON(in: String): InteractionModel = {
in.parseJson.convertTo[InteractionModel](InteractionModel.MyJsonProtocol.ImJsonFormat)
}
val none = new InteractionModel((-1), "", (-1), null) {
override def toJSON = "{}"
}
object MyJsonProtocol extends DefaultJsonProtocol {
implicit object ImJsonFormat extends RootJsonFormat[InteractionModel] {
def write(im: InteractionModel) = {
def recWrite(i: InteractionModel): JsObject = {
val next = i.next match {
case null => JsNull
case iNext => recWrite(i.next)
}
JsObject(
"leftOperantId" -> JsNumber(i.leftOperantId),
"operation" -> JsString(i.operation.toString),
"rightOperantId" -> JsNumber(i.rightOperantId),
"next" -> next)
}
recWrite(im)
}
def read(value: JsValue) = {
def recRead(v: JsValue): InteractionModel = {
v.asJsObject.getFields("leftOperantId", "operation", "rightOperantId", "next") match {
case Seq(JsNumber(left), JsString(operation), JsNumber(right), nextJs) =>
val next = nextJs match {
case JsNull => null
case js => recRead(js)
}
InteractionModel(left.toInt, operation, right.toInt, next)
case s => InteractionModel.none
}
}
recRead(value)
}
}
}
}
Please find below a short example which puzzles me.
I must concede that I have some difficulties to manipulate existential types in Scala.
How should I solve the type mismatch line 56 ?
proposer is OK type _$1 while proposers is of type _$1 <: Individual
Thanks in advance,
Maxime.
class Individual(n: String) {
protected val name=n
var preferred: Individual = this
override def toString(): String=name
}
class Man(n: String) extends Individual(n) { }
class Woman(n: String) extends Individual(n) { }
class Marriage(m: Man, w: Woman){
private val man=m
private val woman=w
def this(w: Woman, m: Man) = this(m,w)
override def toString(): String = man+"--"+woman
}
class Matching(){
private var list: List[Marriage] = Nil
def add(m: Marriage): Unit = { list = m ::list }
override def toString(): String= {
var s: String = ""
for (elm<-list) s=s+elm+" "
return s
}
}
object Test{
protected var male = true
def main(args: Array[String]): Unit = {
val al = new Man("Al")
val bob = new Man("Bob")
val alice = new Woman("Alice")
val barbara = new Woman("Barbara")
al.preferred = alice
bob.preferred = barbara
alice.preferred = bob
barbara.preferred = al
val men = Set(al, bob)
val women = Set(alice, barbara)
val m = new Matching()
//var proposers=women
var proposers: Set[_ <:Individual] = Set[Individual]()
if (male) proposers = men
else proposers = women
while (!proposers.isEmpty) {
for(proposer <- proposers) {
val proposer=proposers.head
if (proposer.isInstanceOf[Man])
m.add(new Marriage(
proposer.asInstanceOf[Man],
proposer.preferred.asInstanceOf[Woman]
))
else
m.add(new Marriage(
proposer.asInstanceOf[Woman],
proposer.preferred.asInstanceOf[Man]
))
proposers-=proposer//There is an error here
}
}
println(m)
}
}
This code is messy. It's poorly formatted, it mixes tabs and spaces, and it uses mutability even in the most trivial of places where a functional solution requires little thought.
This code also won't scale internationally to countries where same-sex marriage is a possibility.
Working from the top down...
I suspect you'll never want to directly instantiate an Individual, only ever a Man or a Woman. So a algebraic data type makes more sense, this is done with a sealed trait and case class subtypes.
I'll also drop the preferred property, as it can lead to circular references. Dealing with this in immutable data is beyond the level I'm willing to go in this answer.
sealed trait Individual {
def name: String
override def toString(): String=name
}
//as it's a case class, `name` becomes a val,
//which implements the abstract `def name` from the trait
case class Man(name: String) extends Individual
case class Woman(name: String) extends Individual
Marriage can also be a case class, and let's drop the clumsy duplication of class parameters into vals - it's just pointless boilerplate. This is also a good time to move the auxiliary constructor to a factory method in the companion object:
case class Marriage(man: Man, woman: Woman) {
override def toString(): String = man + "--" + woman
}
object Marriage {
def apply(w: Woman, m: Man) = new Marriage(m,w)
}
Matching is almost pointless, an entire class just to wrap a List? This kind of thing made sense in pre-Generics Java, but not any more. I'll keep it anyway (for now) so I can fix up that toString implementation, which is painfully mutable and uses return for no good reason:
case class Matching(){
private var list: List[Marriage] = Nil
def add(m: Marriage): Unit = { list ::= m }
override def toString() = list.mkString(" ")
}
Finally, the "meat" of the problem. Comments are inline, but you'll note that I don't need (or use) Matching. It's replaced in its entirety by the final println
object Test{
//better name, and a val (because it never changes)
protected val menPropose = true
def main(args: Array[String]): Unit = {
// `new` not required for case classes
val al = Man("Al")
val bob = Man("Bob")
val alice = Woman("Alice")
val barbara = Woman("Barbara")
// remember how preference was removed from `Individual`?
val mprefs = Map( al -> alice, bob -> barbara )
val fprefs = Map( alice -> bob, barbara -> al )
val men = Set(al, bob)
val women = Set(alice, barbara)
// nicely immutable, and using the returned value from if/else
val proposers = if (menPropose) men else women
// no while loop, name shadowing, or mutability.
// just a simple for-comprehension
val marriages = for(proposer <- proposers) yield {
//pattern-matching beats `isInstanceOf`... every time
proposer match {
case m: Man => Marriage(m, mprefs(m))
case f: Woman => Marriage(f, fprefs(f))
}
}
println(marriages mkString " ")
}
}
There's more that can be done here, way more. What of same-sex relationships? What if two or more people share the same preference? What if someone has no preference?
I could also encode the type of someone's preference into Individual instances. But that's getting a bit more advanced.
I have list of many City objects, and at some point after their creation, they will be labelled, so a Label field will be set for each one.
I want to do this in a functional, stateless way, i.e. without setting a default and using var. I'm really just curious as to what the best practice is.
I've got this working example, but I feel pretty funny about it. Notice, in particular, that I'm import-ing the existing City objects, which happens when I call City.addLabel(label).
case class LabelledCity(importCity: CityLike, label: Label) extends CityLike with Labelled
{
val cityState = importCity.cityState
val income = importCity.income
}
case class City(string: String) extends CityLike {
val split = string.split(" --- ")
val cityState = split(0)
val income = split(1).toInt
}
abstract class CityLike {
def addLabel(l: Label): LabelledCity = { new LabelledCity(this, l) }
val cityState: String
val income: Int
}
This all feels a little wrong, or like I'm missing something simple... am I?
Here is the immutable way to archive this (I have dropped class bodies for a sake of simplicity):
case class City(string: String, label: Option[String] = None)
val unknown = City("somestring")
// unknown: City = City(somestring,None)
val washington = unknown.copy(label = Some("Washington"))
// washington: City = City(somestring,Some(Washington))
I have the following class where the properties are an Option[T]
class User extends IdBaseEntity[UUID] {
var id: Option[UUID] = None
var name: Option[String] = None
var createdOn: Option[Date] = None
}
In some data access layer I need to assign these properties if they aren't set before the object is persisted to cassandra. Here are a few ways for the createdOn property. Are any of these the best approach or is there something better I should be doing?
Example 1
entity.createdOn = Some(entity.createdOn.map(identity).getOrElse(new Date()))
Example 2
entity.createdOn = entity.createdOn.orElse(Some(new Date()))
Example 3
entity.createdOn = entity.createdOn match {
case None => Some(new Date())
case _ => entity.createdOn
}
Example 4
entity.createdOn = entity.createdOn match {
case None => Some(new Date())
case Some(x) => Some(x)
}
Example 5
entity.createdOn match {
case None => entity.createdOn = Some(new Date())
case _ =>;
}
Matching on Option is not really idiomatic (IMHO). I prefer to get orElse or getOrElse. Personally I would go with example 2.
I'm not sure whether this will fit your use case, but it is more idiomatic to make User an immutable case class:
case class User(id: Option[UUID] = None, ...)
and copy it, rather than updating the fields in-place:
val updatedEntity = entity.copy(name = user.name.orElse(Some("Chris")))
I'd consider changing your design a bit - for two reasons:
It looks like the User class should be read-only once initialized, so something like a case class or val instead of var would capture that requirement:
case class User( id:UUID, name:String, createdOn:Date );
It looks like every User is required to have an id, name, and createdOn property set, so Option[] is not a good way to model that.
I often setup a Builder class along side read-only classes to
simplify and decouple the object-construction process from
what the object represents - something like
this
object User {
class Builder {
var id:UUID = UUID.randomUUID()
def id( v:UUID ):this.type = {id =v; this; }
var name:String = id.toString
def name( v:String ):this.type = { name=v; this; }
var createdOn:Date = new Date()
def createdOn( v:Date ):this.type = { createdOn = v; this; }
def build():User = {
assert( Seq(id,name,createdOn).find( _ == null ).isEmpty, "Must set all props" )
User( user, name, createdOn )
}
}
}
Anyway - that's another way to do things ...
Since the scenario is "get a property value and update it if some condition holds", I'd try to encapsulate access to properties. For example:
/**
* Read+write access to property `P` of object `R`.
*/
case class Accessor[R,P](get: R => P, set: (R, P) => Unit) {
/** Utility for updating values. */
def update(record: R, modfn: P => P) =
set(record, modfn(get(record)));
}
class User {
var id: Option[Int] = None;
}
object User {
// For each property of `User` we need to define an accessor,
// but this is one time job:
val idA: Accessor[User,Option[Int]] =
Accessor((u: User) => u.id,
(u: User, r: Option[Int]) => u.id = r);
}
object Test {
import User._;
// We can do a lot of stuff now with accessors, for example set
// default values for `Option[...]` ones:
def setDefault[A,B](record: A,
accessor: Accessor[A,Option[B]],
defPropVal: => B) =
accessor.update(record, _.orElse(Some(defPropVal)));
val user = new User();
// Set user's id, if not defined:
setDefault(user, idA, 42);
}
So instead of defining a specific method for each property for filling in default values, we define a generic accessor for each property. Then we can use them to implement all the other stuff generically.