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

LucaMs

Expert
Licensed User
Longtime User
"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.
clsPerson: 
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.
 
Last edited:
Sort by date Sort by votes

Daestrum

Expert
Licensed User
Longtime User
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)
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
Daestrum said:
post #1
Types are classes.
Click to expand...
???
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).


Daestrum said:
post#2
"DoSomething" is not private to Person (as it's a clsPerson)
Click to expand...
???
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.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
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).
Click to expand...
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
B4X: 
Dim i As Int
Dim s As String
Dim b As Boolean
you also always write
B4X: 
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
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
[I thought I would have attached the sample project but now it seems superfluous to me, the image is enough]
Click to expand...
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
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
and you get the log = you can access private methods of an object if you use CallSubDelayed (or CallSub)
Click to expand...
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)
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
OliverA said:
Why? It is totally ok for programming languages to have implicit design elements. In this case, a sub without an "access specifier" is public.
Click to expand...
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!
 
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
OliverA said:
This makes perfect sense. Think about it. You are in clsPersons. In that class you can access main by Typing Main.
Click to expand...
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.
 
Last edited:
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
It would help you not to make the mistake of declaring a method as public (implicitly) when you want it to be private instead.
Click to expand...
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.
LucaMs said:
Of course, if every private method is accessible as if it were public using CallSub... it's all useless!
Click to expand...
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.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
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.
Click to expand...
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.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
You don't have to have the chance, it has to be forbidden
Click to expand...
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.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
Upvote 0

LucaMs

Expert
Licensed User
Longtime User
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.
 
Last edited:
Upvote 0

OliverA

Expert
Licensed User
Longtime User
LucaMs said:
By doing that, you could only use that object in that specific project, which has that modUtils code module.
Click to expand...
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).
 
Upvote 0

AnandGupta

Expert
Licensed User
Longtime User
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.
 
Upvote 0
You must log in or register to reply here.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…