Android Question Private class variable "visibility".

[LucaMs]

This happens only inside the class itself (but anyway it shouldn't).

 

[Erel]

I haven't read all posts but this is of course an important feature and not a bug. B4X is designed to allow this access. It is not related to Java or OBJC behavior.

The public fields and subs make the class external interface. For example, if you write a library then you cannot change the signature of a public sub as it will break other developers code.
This is not the case with private members as only you, the library developer, have access to those members.
Obviously, you are allowed in the class code to access the private members as the class code is internal. If you later change a private sub signature then you will also change any other code inside the class that is based on these subs. This will not break any other code (=encapsulation).

This feature is used in many libraries and it allows making more subs and fields private.

 

[LucaMs]

not a bug

I must agree but only because it seems to be the same in other languages.

I hope the reason is that I have been awake for 5 minutes , but I don't understand your explanation, why this would be an important feature.

I haven't read all posts

Did you read that "I" have access to the private members of instances of a class from within a single instance of that same class?

Did you read post #8?

 

[Star-Dust]

I think the point is not to make the methods private in an absolute sense, but to external classes that could make an unexpected use of them.

But it is possible that all instances of the class see all private methods, because it is the same developer who created the class that operates on those variables and not an external class / developer

 

[LucaMs]

I think the point is not to make the methods private in an absolute sense, but to external classes that could make an unexpected use of them.

But it is possible that all instances of the class see all private methods, because it is the same developer who created the class that operates on those variables and not an external class / developer

Even the developer who created the class should have the advantages of encapsulation, to avoid making mistakes, so he shouldn't have the ability to access private members of an object, even if he has developed the base class.

Not to mention that he sees all the members in the editor without even distinguishing which are public and which are private.



I would like not to add other posts that Erel would not read (they become too many) and that he would read my previous one (and consequently post #8).

 

[agraham]

I haven't read all posts but

In which case I think you might have missed the missed the point, as I did originally. It is not about encapsulation but about class level versus instance level access to private instance variables. Instances of a class can access the private items of another instance of the same class. @LucaMs seems to think this is wrong, despite it being a long standing feature of many languages

As posted by @OliverA earlier
c# - Why have class-level access modifiers instead of object-level? - Stack Overflow

 

[LucaMs]

@LucaMs seems to think this is wrong, despite it being a long standing feature of many languages

Yes, I think it is wrong, because an OBJECT has its own private members which should be such in any "environment", otherwise it is no longer a closed box, a black box, of which you must have the right to access only its public members.

Anyway, that's the way things are, I can not do anything but accept it (but... it is wrong ).

 

[Erel]

Anyway, that's the way things are, I can not do anything but accept it

True, but I will try to explain why it is like this.
You are comparing things of different importance magnitude.

Think about classes inside a library, such as XUI Views. The public members are a contract between me, the developer who is writing the library, and the developer who is using it.
I cannot change the signature of any public sub without breaking code of many developers, however I can change everything else in the class code freely.
This is the main importance of the visibility feature - to allow the developer to further develop the class without breaking the code of other developers.

There is no reason to limit the class developer from accessing all members. It is very useful. Without this feature, there will be many cases where the developer would have needed to make methods public although they aren't supposed to be called by the developers who use the class (there are still such cases).

 

[LucaMs]

True, but I will try to explain why it is like this.

I really appreciate this, that you still specify even though you know my bad habit of wanting to argue... a little too much

Think about classes inside a library, such as XUI Views. The public members are a contract between me, the developer who is writing the library, and the developer who is using it.
I cannot change the signature of any public sub without breaking code of many developers

Yes, one of the fundamentals of objects is encapsulation, their interface is the contract you mentioned and I agree.

There is no reason to limit the class developer from accessing all members. It is very useful.

I agree less on this. It is true that in that way you have more freedom, the possibility of accessing a private member of an object based on your class, but it can also be a source of errors, if you inadvertently use a private member thinking that it is public.

 

[OliverA]

@lucas, how would you handle an Equals method with your methodology?

Class Test
Priv a
Pub b

Public Sub Equals(obj As Test)
if b = obj.b And a = obj.a then return True
Return False
End Sub

In your case the variable 'a' would need to be made public, defeating the reason of keeping it private.

 

[LucaMs]

@lucas, how would you handle an Equals method with your methodology?

Class Test
Priv a
Pub b

Public Sub Equals(obj As Test)
if b = obj.b And a = obj.a then return True
Return False
End Sub

In your case the variable 'a' would need to be made public, defeating the reason of keeping it private.

The check of the contents of the two objects is right to be done on the properties of them.

 

[LucaMs]

I sent a friend a link to a tutorial on object-oriented programming (he learned it in a "practical" way, so he gets a little confusing in the distinction between class, object, instance, ...).

Well, just to see if I still remember everything and to pass the time, I started reading it myself!

Sentence in that tutorial:
(Italian)
Inoltre, un oggetto non dovrebbe mai manipolare direttamente i dati interni (le proprietà) di un altro oggetto ma ogni tipo di comunicazione tra oggetti dovrebbe essere sempre gestita tramite l’uso di messaggi, ovvero tramite le chiamate ai metodi che un oggetto espone all’esterno.
(English)
Furthermore, an object should never directly manipulate the internal data (the properties) of another object but any type of communication between objects should always be managed through the use of messages, i.e. through the calls to the methods that an object exposes to the external.

I would have added: "not even if the "manipulator object" is an object of the same class"

 

[Star-Dust]

I sent a friend a link to a tutorial on object-oriented programming (he learned it in a "practical" way, so he gets a little confusing in the distinction between class, object, instance, ...).

Well, just to see if I still remember everything and to pass the time, I started reading it myself!

Sentence in that tutorial:
(Italian)
Inoltre, un oggetto non dovrebbe mai manipolare direttamente i dati interni (le proprietà) di un altro oggetto ma ogni tipo di comunicazione tra oggetti dovrebbe essere sempre gestita tramite l’uso di messaggi, ovvero tramite le chiamate ai metodi che un oggetto espone all’esterno.
(English)
Furthermore, an object should never directly manipulate the internal data (the properties) of another object but any type of communication between objects should always be managed through the use of messages, i.e. through the calls to the methods that an object exposes to the external.

I would have added: "not even if the "manipulator object" is an object of the same class"

It seems to me that the answer was clear, another instance of the same object is not considered another object.

Now since all languages implement them like this, why lengthen this thread again?

If you have a different idea of encapsulation, in your place I would create my own language (I suggest the name LM4X) and create a real innovation in the world of computing.

Otherwise we waste bytes of our connection

 

[LucaMs]

Now since all languages implement them like this, why lengthen this thread again?

Just for... fun?

 

[Star-Dust]

Just for... fun?

Yes, but to have fun there must be someone who counters you.

However think about creating a new language, it is not difficult

 

[LucaMs]

Now since all languages implement them like this, why lengthen this thread again?

Okay, I admit it: I hate this thing, which I wouldn't call "feature" at all.

I will write to Bill Gates, James Gosling, Guido van Rossum, ... Joe Biden and I will make sure that this is changed in all programming languages; even in those who are not object oriented!



P.S. and to Erel

 

[Star-Dust]

Okay, I admit it: I hate this thing, which I wouldn't call "feature" at all.

I will write to Bill Gates, James Gosling, Guido van Rossum, ... Joe Biden and I will make sure that this is changed in all programming languages; even in those who are not object oriented!

Better if you write to Steve Jobs, you will have more listening

 

[LucaMs]

However think about creating a new language, it is not difficult

I had thought about it, I wanted to create a language that would allow me to write applications for Android in a similar way to VB Net; obviously it would have generated Java code.

Then I found out that it already existed: it was called B4A (BasicForAndroid) (really!!!)

 

[Erel]

Okay, I admit it: I hate this thing, which I wouldn't call "feature" at all.

I will write to Bill Gates, James Gosling, Guido van Rossum, ... Joe Biden and I will make sure that this is changed in all programming languages; even in those who are not object oriented!



P.S. and to Erel

Please send it by fax.

 

[LucaMs]