You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scala 3 offers two important feature for contextual abstraction:
12
15
13
16
-**Using Clauses** allow you to specify parameters that, at the call site, can be omitted by the programmer and should be automatically provided by the context.
14
17
-**Given Instances** let you define terms that can be used by the Scala compiler to fill in the missing arguments.
15
18
16
19
## Using Clauses
20
+
17
21
When designing a system, often context information like _configuration_ or settings need to be provided to the different components of your system.
18
22
One common way to achieve this is by passing the configuration as additional argument to your methods.
19
23
20
24
In the following example, we define a case class `Config` to model some website configuration and pass it around in the different methods.
Let us assume that the configuration does not change throughout most of our code base.
33
45
Passing `c` to each and every method call (like `renderWidget`) becomes very tedious and makes our program more difficult to read, since we need to ignore the `c` argument.
34
46
35
47
#### Using `using` to mark parameters as contextual
48
+
36
49
In Scala 3, we can mark some parameters of our methods as _contextual_.
By starting a parameter section with the keyword `using`, we tell the Scala compiler that at the callsite it should automatically find an argument with the correct type.
46
67
The Scala compiler thus performs **term inference**.
47
68
@@ -50,30 +71,48 @@ So the program is equivalent to the one above.
50
71
51
72
In fact, since we do not need to refer to `c` in our implementation of `renderWebsite` anymore, we can even omit its name in the signature:
We have seen how to _abstract_ over contextual parameters and that the Scala compiler can provide arguments automatically for us.
62
90
But how can we specify which configuration to use for our call to `renderWebsite`?
63
91
64
92
Like we specified our parameter section with `using`, we can also explicitly provide contextual arguments with `using:`
65
93
94
+
{% tabs using3 %}
95
+
{% tab 'Scala 3 Only' %}
96
+
66
97
```scala
67
98
renderWebsite("/home")(using config)
68
99
```
100
+
101
+
{% endtab %}
102
+
{% endtabs %}
103
+
69
104
Explicitly providing contextual parameters can be useful if we have multiple different values in scope that would make sense, and we want to make sure that the correct one is passed to the function.
70
105
71
106
For all other cases, as we will see in the next Section, there is also another way to bring contextual values into scope.
72
107
73
108
## Given Instances
109
+
74
110
We have seen that we can explicitly pass arguments as contextual parameters by marking the argument section of the _call_ with `using`.
75
111
However, if there is _a single canonical value_ for a particular type, there is another preferred way to make it available to the Scala compiler: by marking it as `given`.
76
112
113
+
{% tabs given1 %}
114
+
{% tab 'Scala 3 Only' %}
115
+
77
116
```scala
78
117
valconfig=Config(8080, "docs.scala-lang.org")
79
118
// this is the type that we want to provide the
@@ -84,15 +123,25 @@ given Config = config
84
123
// this is the value the Scala compiler will infer
85
124
// as argument to contextual parameters of type Config
86
125
```
126
+
127
+
{% endtab %}
128
+
{% endtabs %}
129
+
87
130
In the above example we specify that whenever a contextual parameter of type `Config` is omitted in the current scope, the compiler should infer `config` as an argument.
88
131
89
132
Having defined a given for `Config`, we can simply call `renderWebsite`:
0 commit comments