.jpg "coda 2 update less compiler")
Why did I even start with the :+ then? First of all, it is important to show things to avoid, but in all honesty, I wanted to stay away from a corner case on Scala naming of methods. What this means is that we don’t really need to make a copy of names because it is Immutable – namesWithAlbert can rely on *names* to hold the rest of the list. Lists implementation relies on each element pointing to the next one, so we can see names as a pointer to “Bob” (and then “Bob” points to “Alice”), and namesWithAlbert as a pointer to “Albert”. The important thing to notice is that what allows for the prepend on immutable lists to be efficient is the fact that the original list cannot change. This is the difference between O(n) or O(1), meaning that the first approach will grow linearly with the size of the list, whereas the prepend will take constant time. Now we are using :: (prepend on the list), which is a colossal difference. Val names = List ( "Bob", "Alice" ) val namesWithAlbert = "Albert" :: names That means that you cannot change it to reference another list however, you can add or change its contents. When you create a List as val (or add a final in Java), only the reference to the list is immutable.
#CODA 2 UPDATE LESS COMPILER FREE#
Feel free to check out Scala Type Hierarchy for more about this. It is also worth mentioning that there is AnyRef that corresponds to, and both AnyRef and AnyVal extend from Any. In Scala there is Any and AnyVal, which you don’t need to worry too much about – but it is relevant to know that the Scala Int behaves like Java int because it extends from AnyVal.
Scala is actually a bit different than Java regarding what is seen as a primitive type or an object. This is important to understand when you are dealing with objects or primitive types like int. Even if the reference is immutable, that does not make the data immutable. Remember: just like final, val and var only reflect the immutability of the declared variable. (While ending statements with a semicolon is valid syntax in Scala, it is not common practice.)
#CODA 2 UPDATE LESS COMPILER CODE#
This code is valid for both Java 10 and Scala var age = 23 That said, var is a normal variable that you would declare in Java, where the val is a final variable. This should be your default mindset, and linters like Scalastyle will even flag it as a problem if you do use var on your code. One thing to keep in mind is that you should always use a val unless you have a really good reason to use a var. Now that we are all on the same page, let’s take a look at some of Scala’s syntax, and see how opinionated it is towards Immutability. It’s less error-prone and easier to debug since the value of a variable is initialized with its declaration.No one can change it, so you don’t need to keep track of what other methods/flows may do to your variables.I think I’ve mentioned it a couple of times already, but Immutability is great! Let’s briefly walk through some of its core points. We’ll tackle an Immutability Toolbox soon enough in an upcoming post. I was going to write about them in Part 2, but on second thought, I think it is for the best to devote some time to Building Immutability first. fold that could help us in the immutable world. Functional programming has a lot of advantages, but working really well with immutability is for sure my favorite one.Īt the end of Part 1, I mentioned that we need a good toolkit with. Welcome back to Part 2! In Part 1 we saw Scala as a language that facilitates and drives you towards the functional world.
0 kommentar(er)
