This question already has an answer here:
In ScalaTest is there any difference between `should`, `can`, `must`
(1 answer)
Closed 6 years ago.
Both scalatest and Specs2 have separate matchers for should and must.
However, I cannot find any explanation for why you would use one or the other.
What exactly is the difference?
There is no difference, this is purely a syntactic preference. I personally prefer to use must in specs2 because I think that should can make people think that an expectation is optional.
Related
This question already has answers here:
Large Switch statements: Bad OOP?
(14 answers)
Switch statements are bad? [closed]
(8 answers)
Closed 5 years ago.
In Clean Code, Uncle Bob states that switch statements almost always break Single Responsibility and Open/Closed Principles. So does this mean that I should rarely (the only case he proposes is when switch is buried in an Abstract Factory to create polymorphic objects) use Switch Statements and therefore Enumerations? This brings the question that are Switch Statements really necessary to have in an OO Language?
Swift language for instance seems to favour enumerations (they can carry data and so on). Minimising their usage would be a major decision. Swift being an OO Language, do the same rules apply?
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 7 years ago.
Improve this question
When we read the wikipedia description of the Kotlin programming language, it is stating that:
JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for, with the exception of Scala. However, he cited the slow compile time of Scala as an obvious deficiency.[4] One of the stated goals of Kotlin is to compile as quickly as Java.
How did they achieve that goal? And why is Scala compile time so slow that it was unacceptable for the Kotlin creators? Or - in other words - which features of the Scala compiler make it slower than the Kotlin compiler?
Although I think the question is not well suited for Stack Overflow as it will tend to produce primarily opinion based answers, here is one attempt: You have two different languages, especially concerning the type system, and two completely independent implementations of compilers. So to expect them to have the "same" kind of compilation speed is already a fallacy. I have linked in my comment to another question that examines the speed of the Scala compiler. Basically, it depends on many factors, for example the amount of work that the type inferencer and implicit resolution required by a specific code base.
Nevertheless, I ran a very quick example: I compiled some Project Euler solutions in Kotlin and Scala. This gave me for a fresh re-compile of the whole project:
6 seconds in Kotlin (down to 5 seconds in successive re-builds)
10 seconds in Scala (down to 7 seconds in successive re-builds).
Origin of the source code:
I took this code for Kotlin, changed a lot of imports because apparently the Kotlin standard library changed in the meantime, in order to make it compile.
I took this code for Scala, and converted it into an sbt project with each problem wrapped in an object pXY extends App { ... } and placed it in a package euler.
Then I removed the files for which only one solution existed, ending up with 26 problems. Both projects were compiled with IntelliJ IDEA 15 CE using Rebuild Project.
To give another perspective on this business, I ran wc (word count) on the sources:
// lines words bytes
931 3603 33087 total // Kotlin
261 1166 6472 total // Scala
So now you can either argue that the Kotlin compiler needed to process "more source code" or that the Scala code was "more dense" :)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Placement of the asterisk in Objective-C
What is the differenct between the following:
(Assume we have a class calculator)
Calculator* calc;
Calculator *calc;
Also what is the need for pointers? Is it not possible to omit the star?
There is no difference between those two declarations, you could also do Calculator * calc if you're feeling adventurous.
As far as if you can omit the star, no, you cannot. It is a carry over from C and shows that calc is a pointer to a Calculator, and not a Calculator itself.
There is no difference between the 2 declaration is just an preference for typing.
Every thing on computers uses pointers. You need pointers java, c#, etc use pointers.
No is not posible to omit the star.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Practical uses of a Dynamic type in Scala
It has just been tweeted that Martin Odersky has just added Dynamic into trunk. Apparently, this is HUGE. Why?
Dynamic adds developer driven dynamic binding (dynamic dispatch) and gives a subset of the features of dynamic typing to Scala.
See this pastie from Jorge Ortiz:
http://pastie.org/1469174
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
Or a release candidate? My google-fu fails me.
This is a little out of date, but gives a rough idea:
http://www.nabble.com/Re%3A-Any-guesstimated-release-dates-for-2.8-final--p24919161.html
Based on my experience with the nightlies, and porting some code to 2.8, I would add about 2 months to those estimates. You can get a feel for the activity here:
https: // lampsvn.epfl.ch/trac/scala/timeline
2.8 is a big release, including:
unnested packages
new collections library
hashCode() of mutable collections now throws Unhashable
new arrays
named/default params
case classes generate copy() methods
#specialised
fixed equality / hash code handling across primitives and boxed primitives
RichString replaced by WrappedString
so that "abc".reverse.reverse == "abc"
ability to control annotation targeting (i.e. field, getter or setter; class or constructor)
support for nested annotations
delimited continuations compiler plugin
better compiler support for the Eclipse Scala Plugin
refactored actors implementation
refactored pattern matcher implementation
tweaked rules for implicits
many other bug fixes...
Which is to say that it is likely to take a few release candidates to reach the elusive 2.8.0 status.
Ask the Scala mailing list, Grasshopper.
http://www.scala-lang.org/node/199
2.8.0 Beta 1 Release Candidate 4 was just released. They're getting there!
That's because no firm dates have been set.
I don't think any release date has been set. 2.8 is a big release though, so don't hold your breath.
In the mean time, you can get a nightly build. I've been using the nightlies for several months, and they work pretty well. Before downloading a nightly though, make sure you check the Hudson server to make sure the build actually succeeded.