181–184 of 184 posts
Earlier quoted context omitted.
I wouldn't bother. I'd just go ahead and use 2 distinct APIs directly, and then after a while, I'll realize my code look more and more Javaish, and then I'll switch back to Java.
Ah, ok. So you haven't understood the problem, but wanted to say something. Great.
Earlier quoted context omitted.
An example I use a lot because it is terse: From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value } From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) } That is to say that the default behaviour of a Scala hash map is to create a new object for every access (notice I say access, not for every insert)…
apply?
I enjoyed reading this article, but does anyone who doesn't already understand what they're saying understand after reading something like: "Play's reactive core and asynchronous libraries (e.g. WS) integrate seamlessly with other powerful concurrency primitives in the ecosystem such as Akka’s actors. Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchro…
A for-comprehension from our production code: for { createResult That code asynchronously updates both ElasticSearch and Neo4j. Those functions all return Scala futures containing JSON values. First the new object is created in Neo and then the index in ES is updated accordingly. This is in a controller action in a Play project where it's critical to keep everything non-blocking. If everything is successful, Play ret…