Strange Private Variables - Why does this work?

[CJ]

Hi,

Came across this issue - anyone know why this works?

public class Cat {
private int privateVal;
public void test()
{
Cat c1 = new Cat();
c1.privateVal = 1;
}
}

Surely the "privateVal" variable should not be accessible at this
point (should be out of scope)? Anyone care to enlighten me??

Thanks

CJ

 

[VisionSet]

Hi,

Came across this issue - anyone know why this works?

public class Cat {
private int privateVal;
public void test()
{
Cat c1 = new Cat();
c1.privateVal = 1;
}
}

Surely the "privateVal" variable should not be accessible at this
point (should be out of scope)? Anyone care to enlighten me??

private members are available to *any* code in the same class

 

[Joona I Palaste]

Hi,

Came across this issue - anyone know why this works?

public class Cat {
private int privateVal;
public void test()
{
Cat c1 = new Cat();
c1.privateVal = 1;
}
}

Surely the "privateVal" variable should not be accessible at this
point (should be out of scope)? Anyone care to enlighten me??

Thanks

It's a bug/feature (choose one) in Java that objects in the same class
can access each other's private variables.
It's not a scope issue but a visibility issue. IMHO it breaks the
"encapsulation" idea but it can solve a lot of practical problems.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[VisionSet]

Hi,

Came across this issue - anyone know why this works?

public class Cat {
private int privateVal;
public void test()
{
Cat c1 = new Cat();
c1.privateVal = 1;
}
}

Surely the "privateVal" variable should not be accessible at this
point (should be out of scope)? Anyone care to enlighten me??
CJ

And it's not a 'scope' issue, it's a 'visibilty' one.

 

[Phillip Lord]

Joona> It's a bug/feature (choose one) in Java that objects in the
Joona> same class can access each other's private variables. It's
Joona> not a scope issue but a visibility issue. IMHO it breaks the
Joona> "encapsulation" idea but it can solve a lot of practical
Joona> problems.


Just depends how you look at it. Variables are private to the class,
and not the object. In this case you are calling the private variable
from the same class.

It makes sense to me. The point of privacy is to say "you should only
be changing this if you know what you are doing". If you have
implemented Cat, then you should know what you are doing with all
objects of Cat.

Phil

 

[Joona I Palaste]

Joona> It's a bug/feature (choose one) in Java that objects in the
Joona> same class can access each other's private variables. It's
Joona> not a scope issue but a visibility issue. IMHO it breaks the
Joona> "encapsulation" idea but it can solve a lot of practical
Joona> problems.

Just depends how you look at it. Variables are private to the class,
and not the object. In this case you are calling the private variable
from the same class.

I would have to disagree with the notion "variables are private to the
class, and not the object". If they're not private to the object, then
how come each object gets its own copy of them, and can alter them to
its heart's content without disturbing the other objects of the same
class? Huh?

It makes sense to me. The point of privacy is to say "you should only
be changing this if you know what you are doing". If you have
implemented Cat, then you should know what you are doing with all
objects of Cat.

I'd take that point of privacy one level further, and allow one single
*object* to only modify itself willy-nilly. After all, objects are a
more usable concept than classes, which can be shown by the existence
of languages with objects but not classes, whereas I don't know any
with classes but not objects.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am lying."
- Anon

 

[Tor Iver Wilhelmsen]

I would have to disagree with the notion "variables are private to the
class, and not the object". If they're not private to the object, then
how come each object gets its own copy of them, and can alter them to
its heart's content without disturbing the other objects of the same
class? Huh?

Because you're confusing two totally different meanings of "private"
here. There is private as in "uniquely belongs to" (your use) and
private as in "the Java access modifier" (the use under duscussion).
In the latter case, a private member of an instance of a class is
accessibe to *any* code in that same class that can get at that
instance.

 

[Joona I Palaste]

Because you're confusing two totally different meanings of "private"
here. There is private as in "uniquely belongs to" (your use) and
private as in "the Java access modifier" (the use under duscussion).
In the latter case, a private member of an instance of a class is
accessibe to *any* code in that same class that can get at that
instance.

So let me get this straight, Java provides no way of having private
as in "uniquely belongs to"? In that case Java is IMHO breaking one
principle of "good" OO. Another such breach is the existence of non-
polymorphic primitives. It could also be argued that static variables
and methods are also breaches against "good" OO.
However, no one ever claimed Java was a *pure* OO language.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio

 

[Christophe Vanfleteren]

So let me get this straight, Java provides no way of having private
as in "uniquely belongs to"? In that case Java is IMHO breaking one
principle of "good" OO. Another such breach is the existence of non-
polymorphic primitives. It could also be argued that static variables
and methods are also breaches against "good" OO.
However, no one ever claimed Java was a *pure* OO language.

Is that really such a problem in real life?
Seriously, if a programmer is designing and coding the class, he sure knows
(or should know what he's doing with any instance of the class.
Also, how would you start to implement methods like equals/compareTo if you
can't reach the other object's private fields? Objects would only be able
to be compared on public properties, wich might not work in some
conditions.

 

[Joona I Palaste]

Joona I Palaste wrote:
(snip)

Is that really such a problem in real life?
Seriously, if a programmer is designing and coding the class, he sure knows
(or should know what he's doing with any instance of the class.
Also, how would you start to implement methods like equals/compareTo if you
can't reach the other object's private fields? Objects would only be able
to be compared on public properties, wich might not work in some
conditions.

Here's a solution. Divide the "private" visibility modifier into two
new ones: "really private" and "soft-of private" (they need better
names). A field or method that is "really private" is only ever visible
to the object it belongs to. A field or method that is "sort-of
private" is only ever visible to objects of the same class.
Fields that the equals and compareTo methods need would be "sort-of
private". Everything else (that used to be private) would be "really
private".

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"We're women. We've got double standards to live up to."
- Ally McBeal

 

[Michael Borgwardt]

Here's a solution. Divide the "private" visibility modifier into two
new ones: "really private" and "soft-of private" (they need better
names). A field or method that is "really private" is only ever visible
to the object it belongs to. A field or method that is "sort-of
private" is only ever visible to objects of the same class.
Fields that the equals and compareTo methods need would be "sort-of
private". Everything else (that used to be private) would be "really
private".

Additional complexity with no benefit.