-
Notifications
You must be signed in to change notification settings - Fork 32
/
TODO
125 lines (90 loc) · 6.8 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
------ SERGIO COMMENTS --------
In general
- Consider grouping type types into "big boxes" - is it possible to split types into groups of types?
- I can go tomorrow over the things below.
Page 2
- I think the the use of inferred on the example can be a bit muddied:
"// without Type Annotation, the type is inferred to be `Thing`
val inferred = getThing"
Maybe an example of a different domain?
"trait Dog
def getDog = new Dog
// without Type Annotation, the type of laika is inferred to be `Dog`
val laika = getDog"
- "Related hint: Including Type Annotations speeds up compilation, also it's generally nice to see the return type of a method." -> I would personally put these two ideas in the next paragraph, saying something like "Best practices are ... for ... reasons"
Page 3
- "typesystem" or "type system"?
- Java primitive list is missing char
Page 4
- I really like the style of the example at the beginning of this page, the comments clarly showing what´s going on under the bonnet.
- "This way, by having a smart compiler and treating everything as an object in this common hierarchy we're able to get away from the "but primitives are different" edge-cases, at least at the level of our Scala source code - the compiler takes care of it for us." -> I think this is too hard to read due to length, consider breaking it down. Also, I would say "but primitives are different" sounds a bit whiny, I would remove the "but".
Page 6
- I would talk about calling type with the verbose option before the example, as in "by using :type again on it with the verbose option to get some extra info..."
- Last phrase I would remove the "I" and make the subject of the phrase the example ("This example nicely exemplifies the core functionality...")
Page 7
- Maybe break "Coming back to the subject why the common Type for our if statement with an AnyVal on one code block and a null on the other one was Any and not something else" down into two?
- "obviously" as an adverb is modifying the verb "implemented", which I´m not sure if it´s what you are going for. Maybe substitute for "As it is obvious, since it is..."?
- "How it might look like in your code is explained by the bellow example:" -> I would join with the previous paragraph and revert it: "You can see how the code would look on the below example"
- On type variance, I would try to elaborate a bit more at the beginning - don't make paragraphs with a single line.
Page 8
- "One being "any collection", where we'll use a List[A] as our example, and functions." -> Don´t understand the "and functions" at the end.
- "Scala..., which..., under..." -> I feel this phrase has bad rythm, try not make it a bit more fluid: "Scala has Traits, which in other languages -such as Ruby- are known with the name of Mixins"
- "First..." -> maybe it´s a good idea to explain what a trait is before going on into detail?
Page 9
- "diamond problem" or "The Diamond Problem"
- A reader could ask, why are we not sure? Also, the usage of "Basically" feels colloquial. "Basically "The Diamond Problem" is a situation during multiple inheritance where we're not sure to what we want to refer to."
Page 10
- "This introduces an ambiguity when calling the common method in D , did we inherit the version of the method from C or from B ?" -> Make point of view homogeneous.
- What is "In Scala's case the case with only one overriding method is very simple - the override wins." referring to?
- "always (and deterministically) able to determine what will be called" -> "always able to deterministically identify which method implementation will be called"
- On the examples, I would do away with the asserts, make it more like the previous ones.
Page 11
- "So for example in our case ( D1 ), the superclass of C is B." -> What about poor D2? You could say smthing such as "and viceversa fro D2" to keep symmetry.
Page 12
- "Using this trick the ### definition now suddenly "makes sense!" -> Disagree, have no idea what just happened :P Explain more!
- "Let's now go deeper into the..." -> I would remove the "taking the readers along" metaphor, it is very difficult to maintain on a long and technically deep text.
Page 14
- All text under Type constructor I found difficult to parse.
Page 15
- "used this trick before" -> did we? Link back to section maybe?
Page 16
- "why this us so nice interesting... [example] ...And we can do the" -> you didn´t tell the reader why it was so nice/interesting, something like ¨Look at the type of the parameter..."
- I would join the example for stop to the start one and expand on the case for either (smthing like "What if you need to accept parameters in a subset of states...")
Page 17
- Love the example, but don´t understand "//takes a java.io.File (implements Closeable)"
- "Another fact " -> "An important fact"
- "investitage the generated bytecode for scala (or java) classes, by using :javap in the Scala REPL, so you can check it out yourself." -> "investigate" and remove commas.
Page 18
- Repeated the performance warning, either remove or lampshade/excuse the repeat.
Page 20
- On existential types, I feel the example is difficult to understand on its own, and the explanation expects a lot from the reader.
- "We know though that List is a type constructor, * -> *" -> do we? I would try to expand on this paragraph and make it more accessible.
Page 21
- You said the "M" word! Scary! Is it possible to have a more pedestrian example?
Page 23
- This sounds a bit weird -> "You can try it out (it's copy paste ready) in your Scala 2.10+ REPL - if you don't have one at hand: yeah, the output would be:" -> just say somehting like "The output would be"
Page 24
- "Yeah, you figured it out already I guess." -> Well no, I didn´t...
------- END OF SERGIO COMMENTS -------
----------- BAMBUCZA -------------
Łukasz Dubiel @ 01:06
Nie wiem czy w momencie kiedy tłumaczysz trochę curring nie przydałby się rysunek do tego
brakuje calli przy type projection
tzn pobrałeś wartości do vali
ktoso @ 01:07
hm, jakies defy chcesz tam?
Łukasz Dubiel @ 01:07
wiesz jak wcześniej miałeś, że typy się nie zgadzają to tutaj by już mogły
ktoso @ 01:07
oh ok
----------- END OF BAMBUCZA -------------
------------------ DAN -------------
structurals need more of an intro
----------- END OF DAN -------------
------------- JOSH SECTION --------------
a higher kind is not exactly a type constructor. A type constructor enables higher kinds - in methods for example.
show how List[_] gets desugared into forSome, show also that we can abstract over that value
`type of object` section can be made longer - it's actually how the compiler looks up all the types.
On the object of java.lang#String it looks for String. // projection or path dependent here? actually
Expand section on type level - include >: and <: and those.
------------- END OF JOSH SECTION --------------