i say "hardcode dependencies" for three reasons:

- If you want to extract them out, it's safe and straightforward. Still a tedious refactor, but a safe tedious refactor. It's not any harder than injecting stuff up-front. Given that, why do the work now if it's not any harder to do later, and you may not need to do it?

- If you hardcode dependencies except for those you can't hardcode, that means that if you come across something which isn't hard coded, you know immediately there must be some reason it needs to be injected in! This makes reading code easier, since following this convention the code itself tells you how it's used, vs having to guess whether an injected dependency is actually necessary or whether it has just one instantiation and can be hardcoded

- You are already hardcoding all sorta of things anyway. The `Seq` object? The `String` type? These, and other things, can be injected in as params or type-params if we really want to. The question is then when do you stop and draw the line? You obviously can't inject everything. "Only inject stuff that needs to be injected" provides a clear, unambiguous guideline that applies equally to dependencies on your code, on the std lib, or on third party libraries

On a semi-related note, here[0] is a talk given by a gentleman named Runar Bjarnason discussing a Dependency Injection technique in Scala.

Related in that you mentioned dependency injection, unrelated in that it is not directly relevant to the content of Strategic Scala Style. (maybe of interest to some though).

0 - https://yow.eventer.com/yow-2012-1012/lambda-the-ultimate-de...

> Explicitly declare the return type of all public methods.

+1

This is very helpful for quickly scanning code.

>Again, IMHO, while Option is an exceptionally useful type, when indicating errors at the "public API level" it proves to be insufficient.

Agreed. Either, or even better, \/ (Scalaz either/disjunction) is much easier to work with and more expressive.

I don't type-ascribe all public methods. Maybe I should but I'm lazy. I don't even type-ascribe my implicit vals or defs... i probably should but i don't

As to Either, I didn't mention it because I don't use it much, and don't see many other people using it either. Sure you can use it and it'll work, but it's not the style I use or the style I see most open source libraries using.

As for Scalaz, yeah \/ is great, or cats' Xor. But this doc is all about Vanilla Scala: for every library out there, they will have their own best practices, that are totally uninteresting to people not using hat library. If someone wants to write similar documents for Scalaz, Cats, Akka, Play, Finagle, Play, they would each probably be just as long as this one, and probably just as valuable!

I rarely use Either. If logic is internal to my program, often the cause of the deviation from the happy path is implicit, and I can just use Option. But if I do want to propagate the cause, usually I prefer to model directly within my types as a sealed trait, because then I can easily model multiple causes. Of course, this comes up short if I want to reuse the same cause for multiple distinct outcomes. Either could be nice for this, but it comes up short for multiple causes, because you have to resort to nested Either. Consequently, I very rarely use Either.

What I'd really like is a simple type union syntax, so I could union the happy path result with any number of failure modes, where there isn't necessarily a common supertype for anything.

I really dislike Either personally. I much prefer Scalatic's "Either with attitude" Or. It's also the only natural use of infix type notation I'm familiar with so that's kind of neat.

I frequently see Either abused to represent the lack of Union Types. But then I also see it used for errors. And it's not really a perfect fit for either (no pun intended).

http://www.scalactic.org

Every (a non-Empty List) is also nice. I like Scalactic. It adds just a couple of small useful things. Very lightweight.

Option (Some or None), Or (Good or Bad) and Try (Success or Failure[T <: Throwable]) cover the bases for me.

Just in case others were unaware of scalactic. (sister library to scalatest, so if you're already using scalatest, you're already using scalactic under the covers I believe)

Using `Either` instead of `Option` would violate "Use the least complex approach that solves your problem".

If all you need is represent an optional value, why use `Either`, which needs a second type parameter representing the failure? If you don't care about what caused the failure (because there was no failure, an absence of value is a valid result), no need to represent it.

Besides, these two classes still represent fundamentally different concepts and they are not interchangeable at all.

Find something you want to do, try to do it, find out what you don't know, and learn it.

You could try learning from a book or a course, but personally I've never found a better way of learning "what I need to learn for X" than trying to do X and then googling all the things I don't know.

Sure, you'll forget a whole bunch of that stuff, but if it's at all important you'll find yourself re-learning it again and again until it sticks.

Scala by example and the coursera courses by Martin Odersky have helped me, but like Li said, there is no substitute to having something in mind and getting your hands dirty using Akka, Play or Spark and Googling what you don't know.

http://www.scala-lang.org/docu/files/ScalaByExample.pdf