Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
There is a web app that uses the following stack on the server:
akka-persistence/service-layer/akka-http (for REST)
The question is :
how can I - in the most elegant, most dry way - make sure that only those users can execute a function in the service layer who are authorized to do so (under the given input parameters).
So for example let's take the simple example:
getEntity(userID:UserID, ref:EntityID):Entity = ???
how should I modifiy getEntity such that only those users are allowed to execute it where the userID of the caller is the same as the userID in the parameters?
What is the most elegant, composable, dry way to do this in general ?
Using custom monads?
Using continuation monads?
Using akka-http style directives?
Using implicits?
Using Free-Monads?
Using Arrows?
Using Kleiesly ?
I cannot really imagine.
How I would do it would be to use an implicit context:
getEntity(userID:UserID, ref:EntityID)(implicit c: Context): Entity = ???
and then whatever is in the context is up to you, i.e.
trait Context {
def canExecute(userId: UserID): Boolean
}
You may want to break this out so you have roles, permissions, etc. Also, if you are using a type parameter then you can use a context bound and make it a bit cleaner:
trait Context[A] { ... }
def getEntity[A: Context](userID:UserID, ref:EntityID): Entity = ???
Implicit parameters are great for being able to pass through contextual information like "current security context" or "correlation id" that is not core to the domain logic but has to be involved all the way down the stack.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
Is a trait a good way to put together all the constants that will be used by certain classes?
Or is there maybe a better way to handle constants, like a package object?
Singleton objects can contain fields, like any other object. If a constant exists on its own, it makes sense to put it in a singleton. Don't make a singleton just for all constants, but if they're logically grouped together, then you could pretty easily make an object with a good name.
object Calendar {
val DaysInYear = 365
val DaysInWeek = 7
val EpochYear = 1970
// ... etc ...
}
Package objects are deprecated in Scala 3 and set to be removed in the future. If you're already using Scala 3, then you can just put individual constants at the top-level of a file. Otherwise, throwing them in a singleton is the most future-proof way to code right now.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
According to https://docs.swift.org/swift-book/LanguageGuide/Functions.html
We can design our function as
With argument label
func someFunction(firstParameterName: Int, secondParameterName: Int) {
// In the function body, firstParameterName and secondParameterName
// refer to the argument values for the first and second parameters.
}
someFunction(firstParameterName: 1, secondParameterName: 2)
Or
Omitting argument label
func someFunction(_ firstParameterName: Int, _ secondParameterName: Int) {
// In the function body, firstParameterName and secondParameterName
// refer to the argument values for the first and second parameters.
}
someFunction(1, 2)
Is there any rule-of-thumb, or best practice we should follow? So that, we know when we should have argument label, and when we should omitting argument label, when come to designing function?
In terms of naming in Swift, you should check out API Design Guidelines. These guidelines will give you a general feel of how to name things in Swift. Fair warning though, these rules are rather theoretical and at the end you are to decide how to name your functions in specific cases. Don't get too hung up on this really, even the most experienced developers have troubles with this, so I've been told.
In your particular situation you definitely shouldn't omit argument labels because type information is very generic and doesn't provide any clue as to what you're passing in.
Hope this helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Going through various Scala related material, term DSL is used at many places.
Google search tells it is Domain specific language.
What exactly it means, and why is it that this term doesn't comes across while learning other languages like Java?
As others have pointed out, the first part of the question ("what is a DSL?") is essentially answered by What is a DSL and where should I use it?
I'll try to answer instead to the second part: why are DSLs so popular in Scala?
The reason is that Scala (as opposed to other languages like Java) offers many syntactic facilities to provide DSLs.
For example, Scala has infix method applications:
someObject.someMethod(someArgument)
// can be written as
someObject someMethod someArgument
This makes introducing custom "operators" very easy in the language. A notable example is the akka DSL for sending messages to an actor:
actor ! message
which is a DSL mimicking the syntax of Erlang.
Another example of a syntactic facility in Scala is the "trailing block argument" (not sure it has a precise name):
def someMethod(x: Int)(y: String) = ???
// can be invoked as
someMethod(42)("foo")
// but also as
someMethod(42) { "foo" }
which is very interesting when the last parameter is a function:
def someOtherMethod[A, B](x: A)(f: A => B): B = ???
someOtherMethod(42) { a =>
// ...a very long body
}
In other languages, blocks ({ ... }) are usually reserved to built-in control-flow structures (such as if, while, for, etc), but in Scala you can use this syntactic facility to build custom methods that resemble built-in control structures.
Those two features alone are distinctive enough for explaining why DSL are so pervasive in the Scala community.
Digging a bit deeper, we can also mention implicit conversions, which allow to add custom methods to any existing type. For example
implicit class TimesOps(x: Int) {
def times(y: Int): Int = x * y
}
// then use as
2 times 4 // 8
This example combines the use of infix method application and implicit conversions.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I'm putting some test cases and having lots of parameters yet it is cumbersome and not so easy to understand putting them into a liner in scala. I rather specify in a visually acceptable manner but correctly parse them in scala...
I would use String Interpolation to define the arguments such as below
val kafkaServers = "server1:9092,server2:9092"
val pleasentArgs = s"""
--master='spark://someserver'
--metricWindowSize=50
--outputDirectory='/tmp/someGoodDirectory'
--zkQuorum=$zkQuorum
--saveToHDF=false
--userName='jack#somewhereElse.com'
--kafkaServers=$kafkaServers
"""
And have a method to clean up all the newline, tab etc characters and then generate the args as shown below:
def cleanUp(str:String) = str.split('\n').map(_.trim.filter(_ >= ' ')).mkString(" ")
def genArgs(args:String): Array[String] =cleanUp(args).split(" ").filter(!_.trim.isEmpty)
So eventually we can just call genArgs method
val args = genArgs(pleasentArgs)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I understand the concept of None
I also understand how nice it is to have MyObj and also MyEmptyObj but i cant figure out when its better to use None instead of MyEmptyObj and when I should be using MyEmptyObj instead of None. Also I tend not to like to see methods that return Option[MyObj] it clutters my code I prefer to return MyObj and then seamlessly call its methods such as MyObj.toJson and thus MyEmptyObj.toJson will know to represent itself rather than having case None: return some empty json what do you think about this whole subject?
To the other side I can say that None goes very well with flatMap etc, so which to choose?
when to None
and when to Empty?
None is great when you have no default value, but if you have a default, by all means use it.
As a very simple example, if you wanted to define a function called amountOwed, you could do this:
def amountOwed(bill: Int, alreadyPaid: Option[Int]): Option[Int] = {
val owed = bill - alreadyPaid.getOrElse(0)
if(owed == 0) None // nothing to pay!
else Some(owed)
}
But that's much more complex (and annoying) than it needs to be, since 0 makes perfect sense as both a "haven't paid anything" and "don't owe anything":
def amountOwed(bill: Int, alreadyPaid: Int): Int = {
bill - alreadyPaid
}