Added empty initial Overview files

[alvinj]

I just created these initial files so that Jonathan and I can get started on the writing process.

[julienrf]

Thank you @alvinj :)

I really like how you explain basic things. However, I often think we give too much information for a “Taste of Scala” (but others may have a different opinion). Please see my comments below.

Also, please don’t open PRs against scala/docs.scala-lang:master but create a branch on scalacenter/docs.scala-lang.org instead. (for instance scala-3)

[julienrf]

These are methods.

[alvinj]

One of my questions for you (all) is, what is the difference between a method and a function, or when should I use those two words? I know that technically a function is defined as a val, but is there ever a time when a def method should be referred to as a function?

[julienrf]

The difference is purely technical: a function is a value (of type A => B), whereas a method is a member on a type. Functions come from FP, whereas methods come from OOP. But, in the end, they do the same: computing something for some input parameters. This is why it is easy to convert a method to a function, and it is also common (although not strictly correct) to talk about function for def methods.

[julienrf]

The syntax has changed again, IIRC it should look like the following:

Suggested change

	def (s: String) hello: String = s"Hello, ${s.capitalize}"
	extension (s: String)
	def hello: String = s"Hello, ${s.capitalize}"

[alvinj]

Thanks. @b-studios caught this one, and I think I’m going to do something like this here:

extension (s: String):
  def hello: String = s"Hello, ${s.capitalize}"
  def aloha: String = s"Aloha, ${s.capitalize}"

"world".hello    // "Hello, World"
"friend".aloha   // "Aloha, Friend"

[julienrf]

I think this section is too detailed too, but I’m not sure how we should present the benefits of implicits without going into all these explanations.

What do you think of the following?

---

Under certain circumstances, the Scala compiler can “write” some parts of your programs. For instance, consider a program that sorts a list of addresses by two criterias: city name and then street name:

val addresses: List[Address] = ...
addresses.sortBy(address => (address.city, address.street))

The sorting algorithm needs to compare addresses by first comparing their city names, and then also their street names when the city names are the same. However, we don’t need to manually define this ordering relation because the compiler is able to summon it automatically based on an existing ordering relation for comparing String values.

---

What do you think?

[alvinj]

Yes, this is a tough one. I’ll think about this some more, but I do like what you have here. It describes what can happen without getting into the details, and it’s motivational in that it makes me want to click a “Learn more about this feature” link in this section.

[alvinj]

Also, please don’t open PRs against scala/docs.scala-lang:master

I’m very sorry if I put this on the master. I thought I created a branch called overview and did my work there. I’m currently wrestling with a printer/scanner, but when I finish with that I’ll look into this.

[alvinj]

Why do you call this "sequence" methods? Because they are defined on Seq? I think at this high-level I would just talk about "collections".

@b-studios, there were probably too many thoughts going on in my head at this time. I was thinking about trying to avoid a discussion of the trait/class hierarchy here. I was also going to make a distinction between sequences and maps, so I was thinking about “methods available on sequences.” But I like @julienrf’s suggestion to simplify this section. When I do that, I’ll get rid of that terminology.