Skip to content

More precise wording in abstract-type-members.md #1287

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 21, 2019

Conversation

fabiopakk
Copy link
Contributor

Dear reviewers,

I summarize below the reason for my changes:

  • Line 37: "Notice how we can use yet another abstract type U as an upper-type-bound." -> That suggests that T <: U, which is not the case.
  • Line 56: Make it clear that the anonymous class is providing concrete types to abstract type members.
  • Line 78: The word 'members' is a must, as 'abstract type' is a broader than intended term. Would also be nice to show and example where abstract type members can't be rewritten with type parameters as claimed.

Dear reviewers,

I summarize below the reason for my changes:
* Line 37: "Notice how we can use yet another abstract type U as an upper-type-bound." -> That suggests that T <: U, which is not the case.
* Line 56: Make it clear that the anonymous class is providing concrete types to abstract type members.
* Line 78: The word 'members' is a must, as 'abstract type' is a broader than intended term. Would also be nice to show and example where abstract type members can't be rewritten with type parameters as claimed.
@SethTisue SethTisue merged commit 307fb5d into scala:master Feb 21, 2019
@SethTisue
Copy link
Member

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants