Skip to content
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

class C(x: R) NOT same as class C(private val x: R) #568

Closed
wants to merge 1 commit into from

Conversation

yanisIk
Copy link

@yanisIk yanisIk commented Sep 9, 2016

It says on the cheatsheet that
class C(x: R) is the same as class C(private val x: R) which is not true.

In this case (class C(x: R)), x is just a parameter that the constructor can receive and is only a local variable inside the constructor and not a member of the class.

It says on the [cheatsheet](http://docs.scala-lang.org/cheatsheets/) that 
`class C(x: R) ` is the same as `class C(private val x: R)` which is not true.

In this case (`class C(x: R) `), x is just a parameter that the constructor can receive and is only a local variable inside the constructor and not a member of the class.
@SethTisue
Copy link
Member

SethTisue commented Sep 12, 2016

I agree the inaccuracy should be fixed, but I'm not sure this is the right way to address it.

I believe the spirit behind saying that (x: R) is like private val x: R was to convey that unlike a Java constructor, x is in scope in the entire class body — making it extremely close kin to private[this] val x: R.

and, note that it isn't accurate wording to say that x is "is only a local variable inside the constructor", because it can be referenced in method bodies in the class, not only in code in the class body that will become part of the constructor.

@yanisIk
Copy link
Author

yanisIk commented Sep 18, 2016

I understand what this is trying to show, but I think this should not be in the cheatsheet, the cheatsheet should be simple and not ambiguous.
For example, I just began to learn Scala and I was thinking the whole time that not specifying the modifier was the same as specifying private and I just recently found out that it's not true and I'm probably not the only one falling into this.

And thanks for the correction, I didn't know that it was also available to the methods and I see now why it is considered almost like a private member.

@SethTisue
Copy link
Member

interested in getting this across the finish line...?

@SethTisue
Copy link
Member

since this seems abandoned I've opened #620 on it

@SethTisue SethTisue closed this Nov 7, 2016
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.

None yet

2 participants