- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala Debate
More relaxed discussions: questions and suggestions on Scala's future, discussions that start elsewhere become but become too specific, topics that are not of general interest.
Re: Yammer moving away from Scala
On 30 November 2011 22:55, Russ Paielli wrote:
>
> I assume that compiling with -optimize takes longer, and that is why it is
> not the default. If it takes no longer to compile (and it works reliably),
> then yes it might as well be the default.
It does take significantly longer to compile large code bases with
-optimize enabled.
Yammer moving away from Scala
I'm surprised I haven't seen this mentioned by now:
Email critique of Scala: https://gist.github.com/1406238
A sample new story on it: http://www.infoq.com/news/2011/11/yammer-scala
It's a very detailed email from an employee at Yammer on why they are
migrating from Scala back to Java. I know it was intended to be private,
but it's gone public now, and there's nothing personal in the email anyways.
Re: Re: Example Issue with Scala API Documentation and Scala Complexity
agreed
On Wed, Nov 30, 2011 at 9:22 AM, Daniel Sobral wrote:
> I'd go with ResultType. Yes, it is a bit redundant in that the
> namespace for it *is* the type namespace, but I think it makes reading
> it easier.
>
> On Wed, Nov 30, 2011 at 13:45, Rex Kerr wrote:
>> I would go with something shorter than ResultCollection; the signatures are
>> long enough already to be hard to parse. "Result" at most, I'd say.
>>
>> --Rex
>>
>> On Wed, Nov 30, 2011 at 10:38 AM, Josh Suereth
>> wrote:
>>>
>>> "That" is used an awful lot in the collection library, and I agree that
>>> better name (like ResultCollection) could be used.
Example Issue with Scala API Documentation and Scala Complexity
I was trying to figure out how to start up a process and capture and
went to
Re: Human perception of complexity
Am 27.11.2011 16:21, schrieb Rex Kerr:
8OFiuTSMRWy9Jai+ThP5obZ_+cdEe0cLiwg [at] mail [dot] gmail [dot] com" type="cite">
On Sun, Nov 27, 2011 at 5:08 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star [at] gmx [dot] de> wrote:
Passing associative parameters to a method?
Hi All
I have a slightly weird thought that I would like to get your opinion
on. Please consider a use case of sending emails as an example. Lets
say I have a "send" method on a Email class. Now the method signature
could look like:
def send(template:String, params: Any*) { }
where template is the name/path of the template I would want to use
and params are the objects that should be bound on the template for
generating the email text.
Re: Actual complexity in Scala that warrants simplification
Or to put it differently: Why should match only take a PartialFunction?
On Tue, Nov 22, 2011 at 1:12 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
On Tue, Nov 22, 2011 at 1:12 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
On Tue, Nov 15, 2011 at 12:28 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
Language improvement proposal - dynamic mixins
Hi everyone,
Currently we can mixin traits either when defining a new class or at
object construction. E.g. I like the fact how I can decorate the Map
with MultiMap:
scala> import collection.mutable._
import collection.mutable._
scala> val map = new HashMap[String, Set[String]] with MultiMap[String,
String]
map:
scala.collection.mutable.HashMap[String,scala.collection.mutable.Set[String]]
with scala.collection.mutable.MultiMap[String,String] = Map()
scala> map.addBinding("first", "1a")
res5: map.type = Map(first -> Set(1a))
scala> map.addBinding("first", "1b")
res6: map.type = Map(first -> Set(1b, 1a))
This is really cool.









