«

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

"CJ" <> wrote in message
news: om...
> 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

--
Mike W

CJ <> scribbled the following:
> 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 () ---------------------------\
| 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

"CJ" <> wrote in message
news: om...
> 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.
--
Mike W

>>>>> "Joona" == Joona I Palaste <> writes:

Joona> CJ <> scribbled the following:
>> 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

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

Phillip Lord <> scribbled the following:
>>>>>> "Joona" == Joona I Palaste <> writes:
> Joona> CJ <> scribbled the following:
> >> 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

> 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 () ---------------------------\
| 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

Joona I Palaste <> writes:

> 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.

Tor Iver Wilhelmsen <> scribbled the following:
> Joona I Palaste <> writes:
>> 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.

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 () ---------------------------\
| 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

Joona I Palaste wrote:

> Tor Iver Wilhelmsen <> scribbled the
> following:
>> Joona I Palaste <> writes:
>>> 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.
>
> 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.

--
mvg,
Christophe Vanfleteren

Christophe Vanfleteren <> scribbled the following:
> Joona I Palaste wrote:

(snip)

>> 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.

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 () ---------------------------\
| 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