Rewrote inner classes tour section #755
Conversation
travissarles
force-pushed
the
inner-classes
branch
3 times, most recently
from
e7fd8fb to
9f8bfd3
Compare
|
Hi Travis. I will take a look later today. At the moment I am UTC+2 in Hamburg but I should have some time later this evening. Thanks for the contribution and talk to you soon. |
|
Sorry not today. 😴 Tomorrow for sure. |
|
|
||
| We now enrich the above example with types to state explicitly what the type of the various defined entities is: | ||
|
|
||
| This program represents a graph as a list of nodes (`var nodes`). Each node knows which other nodes it's connected to (`connectedNodes`). The `class Node` is a _path-dependent type_ because it is nested in the `class Graph`. Therefore, everything in the `connectedNodes` must be created using the class attached to Graph. |
There was a problem hiding this comment.
The var in (var nodes) seems out of place.
There was a problem hiding this comment.
I find "using the class attached to Graph" unclear, in my opinion — I'd suggest trying to find a clearer wording here, even if it requires using more words.
There was a problem hiding this comment.
agree on var nodes, I would expect to see e.g. List[Node] instead or whatever the actual type is
|
|
||
| We now enrich the above example with types to state explicitly what the type of the various defined entities is: | ||
|
|
||
| This program represents a graph as a list of nodes (`var nodes`). Each node knows which other nodes it's connected to (`connectedNodes`). The `class Node` is a _path-dependent type_ because it is nested in the `class Graph`. Therefore, everything in the `connectedNodes` must be created using the class attached to Graph. |
There was a problem hiding this comment.
"Each node knows which..." seems odd. Nodes don't know anything since they don't have thoughts. This would be like saying a chair knows that it has four legs.
| ``` | ||
|
|
||
| This code clearly shows that a node type is prefixed with its outer instance (which is object `g` in our example). If we now have two graphs, the type system of Scala does not allow us to mix nodes defined within one graph with the nodes of another graph, since the nodes of the other graph have a different type. | ||
| Notice how the type of all of the nodes is `graph1.Node`. This is because when we call `graph1.newNode` which calls `new Node`, the method is using the instance of `Node` specific to the instance `graph1`. |
There was a problem hiding this comment.
After the "Notice how" sentence, perhaps insert: "We have explicitly supplied that type, but the compiler would infer it if we had left it out."
| This code clearly shows that a node type is prefixed with its outer instance (which is object `g` in our example). If we now have two graphs, the type system of Scala does not allow us to mix nodes defined within one graph with the nodes of another graph, since the nodes of the other graph have a different type. | ||
| Notice how the type of all of the nodes is `graph1.Node`. This is because when we call `graph1.newNode` which calls `new Node`, the method is using the instance of `Node` specific to the instance `graph1`. | ||
|
|
||
| If we now have two graphs, the type system of Scala does not allow us to mix nodes defined within one graph with the nodes of another graph, since the nodes of the other graph have a different type. |
There was a problem hiding this comment.
This is the key sentence of the entire article. I would suggest stating this very close to the beginning, rather than withholding it until the reader has had to wade through a lot of details.
So at the start, say something like "Suppose we want the compiler to prevent us, at compile time, from mixing up which nodes belong to what graph. Path-dependent types provide a solution."
| @@ -11,7 +11,9 @@ next-page: abstract-types | |||
| previous-page: lower-type-bounds | |||
| --- | |||
|
|
|||
| In Scala it is possible to let classes have other classes as members. Opposed to Java-like languages where such inner classes are members of the enclosing class, in Scala such inner classes are bound to the outer object. To illustrate the difference, we quickly sketch the implementation of a graph datatype: | |||
| In Scala it is possible to let classes have other classes as members. Opposed to Java-like languages where such inner classes are members of the enclosing class, in Scala such inner classes are bound to the outer object. Suppose we want the compiler to prevent us, at compile time, from mixing up which nodes belong to what graph. Path-dependent types provide a solution. | |||
| @@ -31,7 +33,7 @@ class Graph { | |||
| } | |||
| } | |||
| ``` | |||
| This program represents a graph as a list of nodes (`var nodes`). Each node knows which other nodes it's connected to (`connectedNodes`). The `class Node` is a _path-dependent type_ because it is nested in the `class Graph`. Therefore, everything in the `connectedNodes` must be created using the class attached to Graph. | |||
| This program represents a graph as a list of nodes (`List[Node]`). Each node has a list of other nodes it's connected to (`connectedNodes`). The `class Node` is a _path-dependent type_ because it is nested in the `class Graph`. Therefore, all noes in the `connectedNodes` must be created using the `newNode` from the same instance of `Graph`. | |||
travissarles
force-pushed
the
inner-classes
branch
from
0cfedce to
f963d86
Compare
No description provided.