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.
Related
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
Among all the various incomplete lists of features going into Scala 2.10, there are various mentions of improvements to Scaladoc. But it's unclear which ones there are, and which ones are actually going in -- e.g. one of the lists of improvements says "fixes to Scaladoc" with links to various pull requests, some of which got rejected.
Can anyone summarize what's actually changed between Scala 2.9 and 2.10 milestone 4, and maybe indicate what else is planned for 2.10 itself?
Also, are they finally going to fix the problem of not being able to link to methods? E.g. littered throughout my code I have things like this:
/**
* Reverse the encoding computed using `encode_ngram`.
*/
def decode_ngram(ngram: String): Iterable[String] = {
DistDocument.decode_ngram_for_counts_field(ngram)
}
where I want to refer to another method in the same class, but AFAIK there's simply no way to do it. IMO it should be something obvious like [[encode_ngram]] -- i.e. I definitely shouldn't need to give an absolute class (which would make everything break as soon as I pull out a class and stick it somewhere else), and I shouldn't need to give the parameter types if the method name itself is unambiguous (i.e. non-polymorphic).
Several new features, as well as many bugfixes are coming, but there's no definitive list of all the fixes that are in, yet. Of the more notable new features:
Implicitly added members will now be visible. A good example is to look at scala.Array, where methods like map which you might've assumed you had are now visible in the Scaladoc.
Automatically-generated SVG inheritance diagrams, for a bird's eye view of relationships between classes/traits/objects at the package-level and then also at the level of individual classes etc. For example, see the Scaladoc diagrams nightly at both the package-level (click "Content Hierarchy") as well as at the class-level.
Method-linking in some limited form should go into 2.10 (not in the nightly yet). (It's actually not totally trivial to implement in its complete form, due to practical stuff like overloading, as you noted.)
Improved use cases A member with a use case isn't doubly generated anymore, and they're now a bit clearer and simpler than before.
(Less-notable) Keyboard shortcuts for navigating Scaladoc have been added, they're explained here and here
For a more exhaustive list of bugfixes, it might be a good idea to write to scala-internals-- there's a good chance someone will compile a list of all major bugfixes in the past year for you there.
My scala application needs to perform simple operations over large arrays of integers & doubles, and performance is a bottleneck. I've struggled to put my finger on exactly when certain optimizations kick in (e.g. escape analysis) although I can observe their results through various benchmarking. I'd love to do some AOT compilation of my scala application, so I can see or enforce (or implement) certain optimizations ... or compile to native code, if possible, so I can cut corners like bounds checking and observe if it makes a difference.
My question: what alternative compilation methods work for scala? I'm interested in tools like llvm, vmkit, soot, gcj, etc. Who is using those successfully with scala at this point, or are none of these methods currently compatible or maintained?
GCJ can compile JVM classes to native code. This blog describes tests done with Scala code: http://lampblogs.epfl.ch/b2evolution/blogs/index.php/2006/10/02/scala_goes_native_almost?blog=7
To answer my own question, there is no alternative backend for Scala except for the JVM. The .NET backend has been in development for a long time, but its status is unclear. The LLVM backend is also not yet ready for use, and it's not clear what its future is.
This question already has answers here:
Should you always Code To Interfaces In Java [closed]
(6 answers)
What does it mean to "program to an interface"?
(33 answers)
Closed 6 years ago.
I believe that it's better to code to interfaces instead of implementations. In Java:
List<User> users = new ArrayList<User>();
There's no need to specify the runtime type of users all over the program if the code only cares that it implements List.
However, I encounter many people who believe that it's totally fine, even when they're not using properties specific to the ArrayList:
ArrayList<User> users = new ArrayList<User>();
I try to explain that it's redundancy and makes the program harder to change, but they don't seem to care. Are there other reasons that this is important? Or perhaps my convictions are overstated?
Personally, I think that there are two parts to this argument.
If you're returning an object from a method in a class, it should return the most generic object possible. In this case, if you had a choice between returning ArrayList<User> or List<User>, return List<User> because it makes life easier for the people consuming your class.
If you're coding inside of a method and you don't mind hard-coding a concrete type, go for it. It's not what I would do, and it will make your code more fragile in the future but since there are no outside dependencies on that concrete type (hence the first part), you're not going to break anybody that is consuming your code.
Testability is one reason. If you implement using implementations it is very difficult to mock out the required object and use it in tests. You usually end up extending the implementation and overriding which is painful.
It is extremely important if you want to use dependency injection. It is also important for hibernate -- you MUST specify an interface if you have a collection type, because hibernate provides its own collection implementations.
That said, you don't need to be pedantic about it -- sometimes it doesn't matter. Sometimes you want to specify concrete type to get at methods only available on that type.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I can say that I really love Scala but now I would like to know the features you cannot live without when working with Scala? What about Scala 2.8?
If I had to go back to Java here's what I'd miss the most: closures, higher order functions, pattern matching, case classes, and the emphasis on immutability.
I've been on 2.8 for a while. If I had to go back to 2.7, the main thing I'd miss is the consistency, cleanness, and richness of the 2.8 collections API. It's waaaaaay better the 2.7 stuff. But I'd also really miss named and default arguments.
Type inference saves so much pointless typing. map and foreach and the like on collections are great, especially in combination with default-lazy iterators and really easy function syntax.
But, as someone who does a lot of scientific computing, what I'd actually miss the most is being able to write high-performance code, wrap it in efficient classes, and then use maps and mathematical operators (+, *, whatever) to manipulate those high-level constructs the way that I actually think about them.
As for 2.8 vs. 2.7--the improvement is pretty incremental from my perspective. It's a little better in many areas; there's little to point to and say, "Oh wow, that!". I expect the new specialized annotation will help me a lot, but I haven't seen it fully in action in the library yet, so I'm withholding judgment.
I enjoy writing in Scala. That's the #1 feature in my book :)
I can just get on with what I want instead of dancing through Java's hoops:
val/var means I don't have to write the type twice
Closures mean I don't have to write lots of anonymous interfaces and can re-use lots more code
Named parameters mean I don't have to remember the position of each argument - great for both reading and writing
Case classes mean I get toString and equals for free... makes debugging far easier!
A decent API for collections (e.g. map, fold) mean that I can say what I want to do instead of dancing the iteration dance
As for 2.8 vs 2.7... I've only ever really spent quality time with 2.8 ;-)
I think it is not a feature but the conciseness which Scala achieves is what I like the most.
This is of course only possible because of type inference, closures, a great type system etc.
I just do not think you can break it down to one or two features. They work together and the result, concise code, is what I would call the killer feature.
I use a lot of scala maps, occasionally I want to pass them in as a map to a legacy java api which wants a java.util.Map (and I don't care if it throws away any changes).
An excellent library I have found that does a better job of this:
http://github.com/jorgeortiz85/scala-javautils
(bad name, awesome library). You explicitly invoke .asJava or .asScala depending on what direction you want to go. No surprises.
Scala provides wrappers for Java collections so that they can be used as Scala collections but not the other way around. That being said it probably wouldn't be hard to write your own wrapper and I'm sure it would be useful for the community. This question comes up on a regular basis.
This question and answer discuss this exact problem and the possible solutions. It advises against transparent conversions as they can have very strange side-effects. It advocates using scala-javautils instead. I've been using them in a large project for a few months now and have found them to be very reliable and easy to use.