Bug? Scope of private variables in classes

[John C Kirk]

One odd thing I've come across - if you declare a private variable in
a class, it is exposed to other instances of that same class.

To replicate this behaviour, create a class like this:

Public Class Class1

Private mintID As Integer = 0

Public Sub New(ByVal pintID As Integer)
MyBase.New()
mintID = pintID
End Sub

Public Sub Compare(ByVal pobj As Class1)
If (mintID = pobj.mintID) Then
MessageBox.Show("IDs are equal!")
Else
MessageBox.Show("IDs are not equal!")
End If
End Sub

End Class

then create a form with one button, and put this code into the Click
event procedure:

Dim obj1 As New Class1(5)
Dim obj2 As New Class1(4)
Dim obj3 As New Class1(5)

obj1.Compare(obj2)
obj1.Compare(obj3)

When you run the application, you will see two messages: "IDs are not
equal!", then "IDs are equal!". So, it is able to access the private
variables, and it is also looking at the other instance (rather than
retrieving the value from itself).

(I'm using Visual Studio 2003, with v1.1 of the .NET Framework)

I'm not sure whether this is intentional, or a bug - the documentation
seems a bit vague on this point. Personally, I can see where it would
be useful (I came across it when I was investigating deep vs shallow
copying of objects), but I'd prefer the private variables to be
hidden. This reminds me of the way that Friend access works in C++
(rather than VB), where you can explicitly say "Class X has access to
my hidden properties".

John

 

[One Handed Man \( OHM#\)]

No this is correct, Private members of a Class are avauilable to other
instances of the same class. However, you can Shadow this if you inhert the
class .

Regards - OHM

 

[One Handed Man \( OHM#\)]

Actually scrub what I just said, thats not true about shadowing, that wont
help.

OHM

 

[Herfried K. Wagner [MVP]]

* (e-mail address removed) (John C Kirk) scripsit:

One odd thing I've come across - if you declare a private variable in
a class, it is exposed to other instances of that same class.

To replicate this behaviour, create a class like this:

Public Class Class1

Private mintID As Integer = 0

Public Sub New(ByVal pintID As Integer)
MyBase.New()
mintID = pintID
End Sub

Public Sub Compare(ByVal pobj As Class1)
If (mintID = pobj.mintID) Then
MessageBox.Show("IDs are equal!")
Else
MessageBox.Show("IDs are not equal!")
End If
End Sub

End Class

then create a form with one button, and put this code into the Click
event procedure:

Dim obj1 As New Class1(5)
Dim obj2 As New Class1(4)
Dim obj3 As New Class1(5)

obj1.Compare(obj2)
obj1.Compare(obj3)

When you run the application, you will see two messages: "IDs are not
equal!", then "IDs are equal!". So, it is able to access the private
variables, and it is also looking at the other instance (rather than
retrieving the value from itself).

That's what I would expect:

<msdn>
The Private keyword in the Dim statement declares elements to be
accessible only from within the same module, class, or structure.

I'm not sure whether this is intentional, or a bug - the documentation
seems a bit vague on this point. Personally, I can see where it would
be useful (I came across it when I was investigating deep vs shallow
copying of objects), but I'd prefer the private variables to be
hidden. This reminds me of the way that Friend access works in C++
(rather than VB), where you can explicitly say "Class X has access to
my hidden properties".

It's the /same class/ in the VB case.