Future versions of Scala may use then as a keyword, as stated in SIP-12.
The compiler already shows a warning for it:
Usage of then as identifier is deprecated. It can be used as a keyword in future versions of scala.
Word then is reserved as a possible keyword in future versions of scala. It’s usage as identifier is deprecated. See SIP-12.
I'm using Mockito and have many occurrences of then methods called.
BDDMockito.then(entityService).should(Mockito.times(2)).findBy(any)
Does anyone know if there's an alternative to replace it?
In scala, wrapping any identifier in backticks "`" prevents it from being treated as a keyword.
BDDMockito.`then`(entityService).should(Mockito.times(2)).findBy(any)
This has most commonly been used to allow fields/variables/methods to be named type, but it should work for then as well. It's also sometimes used to embed spaces into identifiers.
case class Bar(`class`: Int, `type`: String) {
def `class with type`: String = s"${`class`}_${`type`}"
}
Bar(42, "skidoo").`class with type` == "42_skidoo"
Have you tried mockito-scala? its API is tailored for Scala and it caters for all the language features that the Java version doesn't
Related
I am very new at Scala and Spark area, and I found a strange grammar usage in the scala inside the Apache beam project and I can't understand.
Here is the strange place:
JavaDStream<Metadata> metadataDStream = mapWithStateDStream.map(new Tuple2MetadataFunction());
// register ReadReportDStream to report information related to this read.
new ReadReportDStream(metadataDStream.dstream(), id, getSourceName(source, id), stepName)
.register();
From the above code, you can see inside the constructor of ReadReportDstream, the first parameter is
metadataDStream.dstream()
If we go inside the dstream() method, you will see the following code:
class JavaDStream[T](val dstream: DStream[T])(implicit val classTag: ClassTag[T])
extends AbstractJavaDStreamLike[T, JavaDStream[T], JavaRDD[T]] {
I am wondering why it uses "metadataDStream.dstream()" in the constructor instead of "metadataDStream.dstream"? What does the "()" do?
It's mostly a question of convention. Methods with empty parameter lists are evaluated for their side-effects. Methods without parameters are assumed to be purely functional, and free of side-effects. You can read more about that here - https://docs.scala-lang.org/style/method-invocation.html (Arity-0 section)
So in that case, we're probably having some side-effects in metadataDStream.dstream(). However, syntactically writing it as metadataDStream.dstream won't be an error.
What is the naming convention in Scala for function returning result wrapped in Future? I have seen code like:
getResult
getResultF
getResultFtr
Or even
getResultFuture
If there is no specific convention then I would like to know what is practiced more.
I usually don't name methods returning Futures any differently. My reason is that this information is already present in the return type, and will be made clear by any decent IDE upon autocompletion.
One exception is in the presence of another similar method that doesn't return a Future but does everything synchronously. In that case, I like to clearly differentiate them:
def fooSync: A
def fooAsync: Future[A]
That's a pattern I've seen in plenty of libraries.
I'm using a library that makes heavy use of macros and applyDynamic. The compiler bug that prevents using varargs with applyDynamic has been causing me a lot of pain, and I'm hoping to find a workaround that allows me to pass a dynamic sequence of arguments into an applyDynamic that then invokes a macro.
I have tried to write a macro that expands the sequence or splat before invoking applyDynamic with little success, but I'm not very comfortable with Scala macros so I might have been doing something wrong.
I hit this problem while using ScalaJS on this line:
literal(seq: _*)
the workaround was simply this:
literal.applyDynamic("apply")(seq: _*)
Explanation: literal (more precisely: scala.scalajs.js.Dynamic.literal) is an object extending scala.Dynamic and the call literal(...) is desuggared to literal.apply(...), which itself should be transformed (if there were no bug) by the compiler to literal.applyDynamic("apply")(...). Well, it's a bit ugly, but one can always remove the sugar himself.
This issue has been fixed since Scala 2.12.5
I just found some scala code which has a strange class name:
class `This is a cool class` {}
and method name:
def `cool method` = {}
We can use a sentence for a class or method name!
It's very cool and useful for unit-testing:
class UserTest {
def `user can be saved to db` {
// testing
}
}
But why we can do this? How to understand it?
This feature exists for the sake of interoperability. If Scala has a reserved word (with, for example), then you can still refer to code from other languages which use it as a method or variable or whatever, by using backticks.
Since there was no reason to forbid nearly arbitrary strings, you can use nearly arbitrary strings.
As #Rex Kerr answered, this feature is for interoperablility. For example,
To call a java method,
Thread.yield()
you need to write
Thread.`yield`()
since yield is a keyword in scala.
The Scala Language Specification:
There are three ways to form an identifier. First, an identifier can
start with a letter which can be followed by an arbitrary sequence of
letters and digits. This may be followed by underscore ‘_’ characters
and another string composed of either letters and digits or of
operator characters. Second, an identifier can start with an operator
character followed by an arbitrary sequence of operator characters.
The preceding two forms are called plain identifiers. Finally, an
identifier may also be formed by an arbitrary string between
back-quotes (host systems may impose some restrictions on which
strings are legal for identifiers). The identifier then is composed of
all characters excluding the backquotes themselves.
Strings wrapped in ` are valid identifiers in Scala, not only to class names and methods but to functions and variables, too.
To me it is just that the parser and the compiler were built in a way that enables that, so the Scala team implemented it.
I think that it can be cool for a coder to be able to give real names to functions instead of getThisIncredibleItem or get_this_other_item.
Thanks for your questions which learnt me something new in Scala!
I'm trying to use a Java library (no source code available) which defines some xxx.xxx.object package. Scala complains about the presence of "object" in the package name, so I can't import from it, and I can't refer to its classes with fully qualified name either.
Is there a way around it?
Wrapping the object in a ` (the quote next to 1) should work.
xxx.xxx.`object`
To complete agilefall's answer, the Scala Language Specification mentions that an import is composed of id:
id ::= plainid
| ‘\`’ stringLit ‘\`’
an identifier may also be formed by an arbitrary string between back-quotes (host systems may impose some restrictions on which strings are legal for identifiers). The identifier then is composed of all characters excluding the backquotes themselves.
Backquote-enclosed strings are a solution when one needs to access Java identifiers that are reserved words in Scala.
For instance, the statement Thread.yield() is illegal, since yield is a reserved word in Scala. However, here’s a work-around:
Thread.`yield`()