PRIVATE not really private ??

Hi,

I recently found out that instances of the same class can read *and* write each other's PRIVATE members. Is this normal OOP?

Class Myclass
PRIVATE 
	myInt is int
END

PROCEDURE MyMethod(objMyClass)
oMySisterClass is MyClass dynamic = objMyClass	// pass some other instance of the same class
oMySisterClass:myInt++

This works! I was totally surprised to see this. Is it conform other object oriented languages, or is this specific Windev behaviour?

/sohan

Hi Sohan

Just guessing here (I'm a beginner myself) but as parameters are passed by reference as a default, surely oMySisterClass is just a pointer to the class passed by parameter, rather than a new instance?


Cheers

Malc

Sure, that is the whole idea. But why can I read/write the private members of the instance being passed? PRIVATE means private, right? Apparently not.

/sohan

Hi Sohan,

If your procedure "MyMethod" is really a method of the class, this is correct OOP. The class know it's own structure. So your method can access private members of the class because it's the same class. The structure is known to itself.

Best regards.

I can understand that its structure is known, but apparently its members are also accessible, for both read and write. It does not seem to matter that it is an entirely different instance. I am surprised.

I thought the whole idea of PRIVATE is to protect your members from 'unauthorized' access from outside. I guess that another instance of the same class is not considered to be 'outside' then.

In the mean while, this new concept has sunk in a bit. I guess it is less alarming than I initially thought. My first reaction was, this is like going back to the dark ages, with global variables flying around all over the place, and never knowing what piece of code is reponsible for changing a value. But on second thought, the piece of code responsible can always be found in the class definition itself, so I guess I can start breathing again.

Thanks for your response.

/sohan

Hi Sohan,

Alexandre is correct. This is normal OOP behavior. A private field/method is accessible to the class in which it is defined. (and only to that class).

Georgio

If it's regular OOP, I guess I will have to get used to it.

It still feels strange to me. When I have two instances of -let's say- a query class running, I don't see any reason why the first instance shoud be able to reference private members of the second instance, other than through designated GET and SET-methods. Just like any other piece of code.

Is there a reason it was designed that way?

/sohan

Hi Sohan,

Well, in the above example, it sounds like you have a derived class ... in this case, it would not have access to the private member.

Now, if you are nesting a private class within another class, then you would have access to the private member from the "other class".

Georgio

(I think I just confused myself :-))

No derivation, no inheritance, nothing.

The class code is:

Class Myclass
PRIVATE 
	myInt is int
END

PROCEDURE MyMethod(objMyClass)
oMySisterClass is MyClass dynamic = objMyClass	// pass some other instance of the same class
oMySisterClass:myInt++

The executing code (lets say a window or a procedure) is:

MyInstance1 is MyClass
MyInstance2 is MyClass
MyInstance2:MyMethod(MyInstance1)

This results in MyInstance1:myInt = 1.

Ah well, it is how it is. No use complaining about it. Like I said, I will just have to get used to it.

Thanks for your reply.

Cheers,
/sohan