[doc] improve strong typing sentence #1981
Conversation
|
The build failure looks foreign to my change |
The fix was merged: #1980 |
|
@joroKr21 thanks, now I need a rebase-feature on github so that I can rebase my branch via web-gui :D |
|
please let me know in case a rebase of the branch is necessary. I would prefer if I don't have to checkout the project (do everything from the web-gui) |
I would assume so. I've also found myself often enough wishing GitHub would provide this UI. |
|
It's fine to merge this without worrying about the CI failure, since it's clearly unrelated. However before we merge let's (hereby) ask @alvinj for a review, since this is an especially prominent part of the book. Also there is one wording here I'm not really comfortable with: "where the compiler kind of writes code for you" — we don't require super-formal language on the site, but I think that's too loose a wording. perhaps "the compiler supplies method arguments for you"? |
|
@SethTisue I see your point but speaking only about method arguments is too narrowed IMO as the compiler does more e.g. in case of typeclass derivation. How about I change it to: |
|
Emphasizing what the programmer doesn't have to do, rather than what the compiler does, makes more sense to me for user-facing documentation. In this case, that's omitting terms that can be inferred from their type and the context. |
|
@martijnhoekstra do you have a concrete idea how to phrase it? |
|
Maybe "Strong types allows you to omit things that the language can infer from the type and the context, like given parameters or the availability of extension methods"? |
|
|
|
Hi @SethTisue, I’m a little swamped with a project deadline coming up this Tuesday, but I’ll be glad to look at this on Wednesday. Or, feel free to go with whatever you all think is good. 👍 |
|
no rush |
… typing ...in combination with type inference
Co-authored-by: Jonathan <jonathan@b-studios.de>
| @@ -136,7 +136,7 @@ Because Scala is considered to be a [strong, statically-typed language](https:// | |||
| - Method type declarations tell readers what the method does, and help serve as documentation | |||
| - Types make your code easier to maintain | |||
| - Scalability: types help ensure correctness across arbitrarily large applications and development teams | |||
| - Strong types enable Scala features like implicits (TODO: I need help on this wording and description) | |||
| - Strong typing in combination with excellent inference enables mechanisms like [contextual abstraction]({{ site.scala3ref }}/contextual/motivation.html) that allows you to omit boilerplate code. Often, this boilerplate code can be inferred by the compiler, based on type definitions and a given context (e.g. method arguments for implicit parameters). | |||
There was a problem hiding this comment.
Hey, maybe you can use {% link _overviews/scala3-book/ca-contextual-abstractions-intro.md %} to point to the book chapter? This has the advantage of being a checked link that is easier to maintain.
|
|
||
| In Scala, all types inherit from a top-level class `Any`, whose immediate children are `AnyVal` (_value types_, such as `Int` and `Boolean`) and `AnyRef` (_reference types_, as in Java). | ||
| This means that the Java distinction between primitive types and boxed types (e.g. `int` vs. `Integer`) isn’t present in Scala. | ||
| Boxing and unboxing is completely transparent to the user. | ||
|
|
||
| {% comment %} | ||
| Add the “types hierarchy” image here? | ||
| - AnyRef above is wrong in case of strict null checking, no? On the other hand, maybe too much information to state this here |
There was a problem hiding this comment.
I agree it is too much info here.
| @@ -136,7 +136,7 @@ Because Scala is considered to be a [strong, statically-typed language](https:// | |||
| - Method type declarations tell readers what the method does, and help serve as documentation | |||
| - Types make your code easier to maintain | |||
| - Scalability: types help ensure correctness across arbitrarily large applications and development teams | |||
| - Strong types enable Scala features like implicits (TODO: I need help on this wording and description) | |||
| - Strong typing in combination with excellent inference enables mechanisms like [contextual abstraction]({{ site.scala3ref }}/contextual/motivation.html) that allows you to omit boilerplate code. Often, this boilerplate code can be inferred by the compiler, based on type definitions and a given context (e.g. method arguments for implicit parameters). | |||
There was a problem hiding this comment.
| - Strong typing in combination with excellent inference enables mechanisms like [contextual abstraction]({{ site.scala3ref }}/contextual/motivation.html) that allows you to omit boilerplate code. Often, this boilerplate code can be inferred by the compiler, based on type definitions and a given context (e.g. method arguments for implicit parameters). | |
| - Strong typing in combination with excellent inference enables mechanisms like [contextual abstraction]({% link _overviews/scala3-book/ca-contextual-abstractions-intro.md %}) that allows you to omit boilerplate code. Often, this boilerplate code can be inferred by the compiler, based on type definitions and a given context (e.g. method arguments for implicit parameters). |
|
This PR is lying around already quite some time and I apologize. Let me just merge it and let's open new PRs for further improvements. |
My go at improving the sentence about strong types which has an open TODO