Other Another "funny" feature similar to "public private variables"

[LucaMs]

"Similar"? ?

I made a mistake (this is very unusual ?), writing "stuff" in a wrong class.

Here I write different classes than the real project but they are fine to show the anomaly (or is it a feature?).
Two classes: clsPerson, clsGroup (which should have an Array of clsPerson objects).
One (empty) code module: modUtils.

My mistake was not to notice that I was writing source code in the clsPerson class while I would have had to do it in the clsGroup, that is to declare in the clsPerson the array of Person objects and the initialization of this Array with clsPerson objects.

Note: clsPerson - the wrong class I was writing in.

Sub Class_Globals
    Private marrPersons(6) As clsPerson
End Sub

Public Sub Initialize
    InitPersonsArray
End Sub

Private Sub InitPersonsArray
    For i = 0 To 5
        Dim Person As clsPerson
        Person.Initialize
        marrPersons(i) = Person
    Next
End Sub

Well, in this class besides seeing the private variables, a topic we have already written about... among the members of an instance of this class (again only inside the class) I see... the modUtils code module! [and the Main Form - I was developing in B4J].

[I thought I would have attached the sample project but now it seems superfluous to me, the image is enough]


P.S.
I just noticed now that the modUtils member is shown as a modUtils type, as if it were a class.
I thought that, although it would be strange, it could be due to the fact that code modules in B4J are very similar to class modules but it is not so, the same thing happens in B4A.

 

[LucaMs]

And this one too:

and you get the log = you can access private methods of an object if you use CallSubDelayed (or CallSub)

 

[Daestrum]

post #1
Types are classes.

post#2
"DoSomething" is not private to Person (as it's a clsPerson) callsub simply calls the named method ("DoSomething") on the object you supply (Person).
just like writing (Person).As(JavaObject).RunMethod("DoSomething",null)

 

[LucaMs]

post #1
Types are classes.

???
From inside the class I'm (was) writing, I see a project code module as if this were a member of the class (and it works at runtime too).

post#2
"DoSomething" is not private to Person (as it's a clsPerson)

???
Under no circumstances should a private member of an object be accessible, otherwise one of the most important features of OOP, encapsulation, is lost.



BTW I would at least add a warning for Subs declared without their "access specifier" (Public / Private) (actually I wouldn't even let the compiler accept it).
I don't need it, I always specify it; I always start writing a Sub by typing pu or pr + Tab.

 

[OliverA]

BTW I would at least add a warning for Subs declared without their "access specifier" (Public / Private) (actually I wouldn't even let the compiler accept it).

Why? It is totally ok for programming languages to have implicit design elements. In this case, a sub without an "access specifier" is public. Do you also give the default values to all your variables that you declare instead of letting the language implicitly assign those values?

So instead of

Dim i As Int
Dim s As String
Dim b As Boolean

you also always write

Dim i As Int = 0
Dim s As String = ""
Dim b as Boolean = False

?
If so, that is ok. But don't force that style onto everyone here. Most of us are fine with the compiler assigning the normal default values to these variables. The same goes with subs being public if the access specifier is left off

 

[OliverA]

[I thought I would have attached the sample project but now it seems superfluous to me, the image is enough]

This makes perfect sense. Think about it. You are in clsPersons. In that class you can access main by Typing Main. and whatever public variable or sub there is. You can also type modUtils. and whatever public variable and method there is. Now you declare a clsPersons variable in clsPersons name Person. It makes totally sense that you can type Person.Main. whatever global variable or sub there is and Person.modUtils. whatever global variable or sub there is. You are still in the clsPerson class and in that class (while actually writing code in the class), the class and any other variables of that class (in this case Person) have access to the same modules/classes/variables and subs. I don't see anything unusual at all here

 

[OliverA]

and you get the log = you can access private methods of an object if you use CallSubDelayed (or CallSub)

Now this one is interesting. What you did leave out is that you had to explicitly write in the sub name in the CallSubDelayed/CallSub routine. The IDE did not help you autocomplete this. And yes, the code gets executed as requested. Now what? If I have a library to which I do not have the source, then the IDE would not help me resolve private subs and this would be a moot point. I would have to keep on guessing to find out what is available. And for what purpose? What is my intent in all of this? And if I have the source to the library and I see these private methods and then choose to use CallSub routines to call those private subs, what is the difference between that and me just rewriting the source of the library to give me access? The way I see it, if I willfully break encapsulation, then I have to deal with the after-effects (if any) of my decision. (Sorta like using undocumented system calls to an OS to get work done, knowing that future releases may break my code. How dare OS developers let me get a hold of those undocumented system calls)

 

[LucaMs]

Why? It is totally ok for programming languages to have implicit design elements. In this case, a sub without an "access specifier" is public.

It would help you not to make the mistake of declaring a method as public (implicitly) when you want it to be private instead. Of course, if every private method is accessible as if it were public using CallSub... it's all useless!

 

[LucaMs]

This makes perfect sense. Think about it. You are in clsPersons. In that class you can access main by Typing Main.

Absolutely not. You can't write code inside an object (class, of course) that accesses external elements that you don't even know if they exist.
By doing that, you could only use that object in that specific project, which has that modUtils code module.

 

[OliverA]

It would help you not to make the mistake of declaring a method as public (implicitly) when you want it to be private instead.

And? You can still accidentally name a method public even though you meant for it to be private. Mistakes can happen, even with explicitly spelling out the access specifier.

Of course, if every private method is accessible as if it were public using CallSub... it's all useless!

No. If I'm the developer and I feel the need to access a private sub in a particular situation without declaring it public for all situations, then this is a perfectly good way of achieving this.

 

[OliverA]

Absolutely not. You can't write code inside an object (class, of course) that accesses external elements that you don't even know if they exist.

But you do know that they exist! modUtils exists. clsPerson can access modUtils and any clsPerson object within clsPerson can access modUtils. There is absolutely nothing wrong with that.

 

[LucaMs]

... if I willfully break encapsulation...

You don't have to have the chance, it has to be forbidden.

 

[LucaMs]

And? You can still accidentally name a method public even though you meant for it to be private. Mistakes can happen, even with explicitly spelling out the access specifier.

Then it is also useless that a warning appears because you declared a variable without specifying its type!

It would be an extra help, not a trivial one.

 

[OliverA]

You don't have to have the chance, it has to be forbidden

No it does not. A language implementation can do whatever it wants to. And I actually like how B4X handles this situation. B4X is a tool to develop, not a tool to showcase some sort of pure implementation of OOP. BTW, show me a "pure" OOP language that is widely used.

 

[LucaMs]

It is my opinion that an object must be encapsulated and its private members must not be accessible externally, without exception. End.

However, we are off topic.

 

[OliverA]

It is my opinion

Exactly

 

[LucaMs]

As an example, and my last post, know that some languages allow multiple inheritance, others, by design and to prevent programmer from making mistakes due to that functionality, have not implemented it.

C++ and Python allow multple inheritance.
Java, VB Net, C# do not.

 

[OliverA]

By doing that, you could only use that object in that specific project, which has that modUtils code module.

Only if you actually use the modUtils code module in your class. If you don't use it, then you don't need to have it. Just because it is accessible while you are writing code in the class, does not mean that it is tied to the class. Why don't you write an example where you actually can produce the case you are talking about (where a class/object suddenly becomes unusable in another project because of the issues you seem to have with the language).

 

[agraham]

Windmills. Tilting At for the purpose of.

 

[AnandGupta]

I remember, Erel has already specified that the classes in B4X are not based on OOP standard as in other languages, like inheritance, encapsulation etc.
So the difference is there compare to other languages.

I take it as B4X OOP standard, no problem in coding there.