-
Jul 3rd, 2022, 06:59 AM
#1
Thread Starter
Frenzied Member
Some unreasonable restrictions in VB6
In a class, we can define a Public property in a simple way, for example:
MyClass1.cls
Code:
Public Name As String
However, in a class, we cannot define a Friend property in a simple way, for example:
Code:
Friend Name As String
Also, we cannot define a Public constant in a VB6 class, for example:
Code:
Public Const DEFAULT_STRING As String = "Hello World"
Why is this?
-
Jul 3rd, 2022, 08:12 AM
#2
Re: Some unreasonable restrictions in VB6
Is that a public property or just a public variable (field?) instead?
Doesn't a property have a specific property definition? If so can they not be declared Friend?
-
Jul 3rd, 2022, 08:34 AM
#3
Re: Some unreasonable restrictions in VB6
Originally Posted by SearchingDataOnly
Why is this?
Both shortcomings of the compiler (that TB will probably fix as these are low-hanging fruits).
Friend variables on a class is a clear omission.
For the public constants it's more complicated as typelibs cannot contain constants on interfaces or coclasses (only in so called "modules" but these are not produced by VB6 compiler at all).
But for *private* classes it's completely possible to expose public constants *and* enums in current project scope only -- alas they didn't put the mental effort to implement it.
cheers,
</wqw>
-
Jul 3rd, 2022, 12:09 PM
#4
Re: Some unreasonable restrictions in VB6
Originally Posted by PlausiblyDamp
Is that a public property or just a public variable (field?) instead?
Yes it's a field. There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.
-
Jul 4th, 2022, 01:05 AM
#5
Re: Some unreasonable restrictions in VB6
Originally Posted by Niya
Yes it's a field.
No, it's a Property.
Originally Posted by Niya
There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.
No, ...
Public L As Long, S As String, D As Date
...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").
Olaf
-
Jul 4th, 2022, 01:11 AM
#6
Re: Some unreasonable restrictions in VB6
The whole "Friend"-Thing in vb6 is one mess.
any serious OOP-Language has (at least) three scope modifiers for Class-Members:
Private, Protected (that's Friend in vb6) and Public
Purpose: Restricting access to those members, especially in regards to inheritance
Private = Like the word says. It's private for this Class/Instance. Keep your nose out of it.
Protected = OK, me and my children can access it. For everyone else: Not your business
Public = Ah well. That's my public face. Use it.
Depending on the Language-Implementation, Protected can be accessible as long as the "Child" is within the same File/Unit (as known from Pascal/Delphi) as its parent. Otherwise it's private
Since vb6 doesn't support inheritance and/or multiple classes per File/module, Friend is basically Public for the Project.
e.g.: You write an ActiveX-DLL in vb6.
You have some Classes there with Private, Friend and Public Members
Private are Private to that class
Public are accessible from outside that DLL
Friend are NOT accessible from outside that DLL, but are accessible (like Public members) from inside that dll from anywhere
Bottom Line: One big Mess
I wouldn't bother with it
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Jul 4th, 2022, 01:53 AM
#7
Re: Some unreasonable restrictions in VB6
Originally Posted by Schmidt
No, it's a Property.
No, ...
Public L As Long, S As String, D As Date
...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").
Olaf
I stand corrected
Originally Posted by Zvoni
Bottom Line: One big Mess
I wouldn't bother with it
You really think so? I get a lot of value out of Friend in .Net since I have a tendency to put non-UI helper classes and methods into a class library(ActiveX DLL in VB6 terms) that is referenced by the project that has the UI. Friend allows me to hide all the excess clutter that is unneeded by the external project using the library while allowing me to access it fully from anywhere within library itself.
I think whether one likes or hates Friend this depends entirely on how you approach programming from an architectural standpoint. If you're someone that just dumps everything into a single EXE, you're not going to appreciate Friend. But if you're someone that likes to spread out your programs over one or more DLLs where each is responsible for a specific set of concerns, you will really learn to love the Friend access modifier. I fall into the second category. I despise monolithic designs and as such I tend toward breaking up an application into multiple components.
Last edited by Niya; Jul 4th, 2022 at 02:04 AM.
-
Jul 4th, 2022, 03:06 AM
#8
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by PlausiblyDamp
Is that a public property or just a public variable (field?) instead?
Originally Posted by Niya
Yes it's a field. There is no short-hand way to define a property like there is in C# and VB.Net. You need the full Get/Let/Set boilerplate in VB6.
Originally Posted by Niya
I stand corrected
As Olaf said, "Public Name As String" represents a Get/Let property, that is, "Public Name As String" is shorthand for Get/Let property.
Code:
Public Property Get Name() As String
Name = m_sName
End Property
Public Property Let Name(Value As String)
m_sName = Value
End Property
Last edited by SearchingDataOnly; Jul 4th, 2022 at 03:10 AM.
-
Jul 4th, 2022, 03:08 AM
#9
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by wqweto
Both shortcomings of the compiler (that TB will probably fix as these are low-hanging fruits).
Friend variables on a class is a clear omission.
For the public constants it's more complicated as typelibs cannot contain constants on interfaces or coclasses (only in so called "modules" but these are not produced by VB6 compiler at all).
But for *private* classes it's completely possible to expose public constants *and* enums in current project scope only -- alas they didn't put the mental effort to implement it.
cheers,
</wqw>
I see, thank you, wqweto.
-
Jul 4th, 2022, 03:09 AM
#10
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by Schmidt
No, it's a Property.
No, ...
Public L As Long, S As String, D As Date
...is defining 3 full Get/Let Class-Properties (as Method-Calls, not "Field-Variables").
Olaf
Yes, you are right. Thank you, Olaf.
-
Jul 4th, 2022, 03:14 AM
#11
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by Zvoni
The whole "Friend"-Thing in vb6 is one mess.
any serious OOP-Language has (at least) three scope modifiers for Class-Members:
Private, Protected (that's Friend in vb6) and Public
Purpose: Restricting access to those members, especially in regards to inheritance
Private = Like the word says. It's private for this Class/Instance. Keep your nose out of it.
Protected = OK, me and my children can access it. For everyone else: Not your business
Public = Ah well. That's my public face. Use it.
Depending on the Language-Implementation, Protected can be accessible as long as the "Child" is within the same File/Unit (as known from Pascal/Delphi) as its parent. Otherwise it's private
Since vb6 doesn't support inheritance and/or multiple classes per File/module, Friend is basically Public for the Project.
e.g.: You write an ActiveX-DLL in vb6.
You have some Classes there with Private, Friend and Public Members
Private are Private to that class
Public are accessible from outside that DLL
Friend are NOT accessible from outside that DLL, but are accessible (like Public members) from inside that dll from anywhere
Bottom Line: One big Mess
I wouldn't bother with it
There is no internal modifier like C# in VB6, so the Friend modifier in VB6 is very important, especially for UDT parameters.
-
Jul 4th, 2022, 03:26 AM
#12
Re: Some unreasonable restrictions in VB6
Originally Posted by Niya
I stand corrected
You really think so? I get a lot of value out of Friend in .Net since I have a tendency to put non-UI helper classes and methods into a class library(ActiveX DLL in VB6 terms) that is referenced by the project that has the UI. Friend allows me to hide all the excess clutter that is unneeded by the external project using the library while allowing me to access it fully from anywhere within library itself.
I think whether one likes or hates Friend this depends entirely on how you approach programming from an architectural standpoint. If you're someone that just dumps everything into a single EXE, you're not going to appreciate Friend. But if you're someone that likes to spread out your programs over one or more DLLs where each is responsible for a specific set of concerns, you will really learn to love the Friend access modifier. I fall into the second category. I despise monolithic designs and as such I tend toward breaking up an application into multiple components.
Niya, i think you misunderstood.
Yes, i also use "Protected" in FreePascal a lot, exactly for the same reasons as you.
My answer was specifically for vb6 and its "Friend"-mechanism
Originally Posted by SearchingDataOnly
There is no internal modifier like C# in VB6, so the Friend modifier in VB6 is very important, especially for UDT parameters.
See above my answer to Niya.
Additionally: IMO, the "Friend"-Modifier only makes sense when writing an ActiveX-DLL/EXE in VB6, since a "Friend"-Member is still public for all others within the (DLL-) Project!
"Friend" only gets a meaning if you access it from Outside (e.g. A "client" referencing your ActiveX-DLL/EXE).
A "classic" for Protected (Friend) are Getters/Setters for Properties, Like in FreePascal
Code:
Type
TMyClass = Class
Private
fSomeInteger:Integer;
Protected
Function GetSomeInteger:Integer;
Procedure SetSomeInteger(AnInteger:Integer);
Public
Property SomeInteger:Integer Read GetSomeInteger Write SetSomeInteger;
Function TMyClass.GetSomeInteger:Integer;
Begin
Result:=fSomeInteger;
End;
Procedure TMyClass.SetSomeInteger(AnInteger:Integer);
Begin
If AnInteger<=0 Then fSomeInteger:=-1 Else fSomeInteger:=AnInteger;
End;
Here, for any Code calling the Class from outside the Unit, only the Property "SomeInteger" is visible.
For any code from within the Unit, the Getter/Setter is visible
That's the "mess" in vb6: In Freepascal (and probably in other modern languages) the "visible" scope for Protected/Friend is the Unit/Module. In vb6 it's the Project!! Not the Class-module itself
Last edited by Zvoni; Jul 4th, 2022 at 03:41 AM.
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Jul 4th, 2022, 03:38 AM
#13
Re: Some unreasonable restrictions in VB6
Originally Posted by Zvoni
Niya, i think you misunderstood.
Yes, i also use "Protected" in FreePascal a lot, exactly for the same reasons as you.
My answer was specifically for vb6 and its "Friend"-mechanism
Friend in VB6 is about the same as Friend in VB.Net in that it allows you to limit types and methods to project in question(ActiveX DLL in VB6 and class library in .Net). Even in VB6 I think it's a great thing to have if you're like me and tend to obsess about avoiding monolithic designs.
I'm curious, what does Protected do in FreePascal? In C/C#/C++/VB.Net it's exactly like Private except it allows access to members by their subclasses in an inheritance chain.
-
Jul 4th, 2022, 03:44 AM
#14
Re: Some unreasonable restrictions in VB6
Originally Posted by Niya
I'm curious, what does Protected do in FreePascal? In C/C#/C++/VB.Net it's exactly like Private except it allows access to members by their subclasses in an inheritance chain.
It's the same.
https://www.freepascal.org/docs-html/ref/refse34.html
5.7 Visibility
For objects, three visibility specifiers exist: private, protected and public. If a visibility specifier is not specified, public is assumed. Both methods and fields can be hidden from a programmer by putting them in a private section. The exact visibility rule is as follows:
Private
All fields and methods that are in a private block, can only be accessed in the module (i. e. unit or program) that contains the object definition. They can be accessed from inside the object’s methods or from outside them e. g. from other objects’ methods, or global functions.
Protected
Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules.
Public
fields and methods are always accessible, from everywhere. Fields and methods in a public section behave as though they were part of an ordinary record type.
And i also stand corrected. The visibility for Protected is not the Unit, but the class itself
Friend in VB6 is about the same as Friend in VB.Net in that it allows you to limit types and methods to project in question(ActiveX DLL in VB6 and class library in .Net). Even in VB6 I think it's a great thing to have if you're like me and tend to obsess about avoiding monolithic designs.
No it's not the same, IMO.
In vb6, I can have multiple Classes within a Project, that don't have anything to do with each other (since vb6 doesn't have inheritance), but within that project i can call any Friend-Member of any of those classes from anywhere within that Project.
In Freepascal i cannot call a protected (Friend) Member of a Class, if my calling code is not a "child" of that class. Within one and the same Project
Code:
Unit UMyClass;
Type
TMyClass = Class
Private
fSomeInteger:Integer;
Protected
Function GetSomeInteger:Integer;
Procedure SetSomeInteger(AnInteger:Integer);
Public
Property SomeInteger:Integer Read GetSomeInteger Write SetSomeInteger;
Function TMyClass.GetSomeInteger:Integer;
Begin
Result:=fSomeInteger;
End;
Procedure TMyClass.SetSomeInteger(AnInteger:Integer);
Begin
If AnInteger<=0 Then fSomeInteger:=-1 Else fSomeInteger:=AnInteger;
End;
Unit UMyClass2;
Uses UMyClass;
Type
TMyClass2 = Class
Public
Procedure DoSomething;
Procedure TMyClass2.DoSomething;
Var
MyClass:TMyClass;
Begin
MyClass:=TMyClass.Create;
MyClass.SetSomeInteger(42); //--> Compilation Fails!!
End;
Unit UMyClass3;
Uses UMyClass;
Type
TMyClass3 = Class(TMyClass) //Inheritance!!
Public
Procedure DoSomething;
Procedure TMyClass3.DoSomething;
Begin
Self.SetSomeInteger(42); //--> Works!! "Self" is "This" in C++
End;
Last edited by Zvoni; Jul 4th, 2022 at 04:01 AM.
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Jul 4th, 2022, 03:53 AM
#15
Re: Some unreasonable restrictions in VB6
Originally Posted by Zvoni
That's the "mess" in vb6: In Freepascal (and probably in other modern languages) the "visible" scope for Protected/Friend is the Unit/Module. In vb6 it's the Project!! Not the Class-module itself
It's pretty much the same. It's just that the namespaces in VB6 coincide with projects i.e. in a project you have only one namespace which is named exactly like your project.
You cannot have multiple namespaces within a project so that friends can be scoped on a particular namespace, so friends gets scoped on the entire project in VB6 which is logical.
It's not that different but still because it's not *exactly* like in C++ (nor in Pascal) it does *not* make it a mess. In VB6 it's just as weird as in C++ and Pascal for someone with different background (say Fortran or OCaml).
cheers,
</wqw>
-
Jul 4th, 2022, 04:00 AM
#16
Re: Some unreasonable restrictions in VB6
Originally Posted by Zvoni
Yea, that's exactly what we have in .Net. But we also have Friend(internal in C#) in addition to those. We also have some interesting combinations, Private Protected and Protected Friend in .Net. Private Protected is like protected except it you it denies access to the member from outside of the project when inheriting. Protected Friend allows project wide access to a member like plain old Friend but it also allows you to access the member outside of the project only from a type derived from the class containing the member(Friend internally, and Protected externally).
-
Jul 4th, 2022, 04:06 AM
#17
Re: Some unreasonable restrictions in VB6
Originally Posted by Zvoni
No it's not the same, IMO.
In vb6, I can have multiple Classes within a Project, that don't have anything to do with each other (since vb6 doesn't have inheritance), but within that project i can call any Friend-Member of any of those classes from anywhere within that Project.
In Freepascal i cannot call a protected (Friend) Member of a Class, if my calling code is not a "child" of that class. Within one and the same Project
Ah I see what the issue is now. You're confusing Protected with Friend. These are two different access scopes. They are not synonymous. As you have rightly pointed out, there is no inheritance in VB6 so a Protected scope makes no sense but a Friend scope still makes sense in the language.
-
Jul 4th, 2022, 09:00 AM
#18
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Hi Niya, I often see code like the following:
Code:
internal class MyClass {
private int _size;
private int _version;
public Clone(MyClass obj) {
this._size = obj._size;
this._version = obj._version;
}
}
Why does C# allow direct access to private members of an object? Closure?
-
Jul 4th, 2022, 10:18 AM
#19
Re: Some unreasonable restrictions in VB6
Originally Posted by SearchingDataOnly
Why does C# allow direct access to private members of an object?
Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).
This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))
Edit: So now you started cross-posting in multiple subforums here and annoy members of both ones -- not very clever. . .
cheers,
</wqw>
-
Jul 4th, 2022, 02:18 PM
#20
Re: Some unreasonable restrictions in VB6
Originally Posted by wqweto
Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).
This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))
Note that this isn't true of VB6 though.
Originally Posted by SearchingDataOnly
Hi Niya, I often see code like the following:
Code:
internal class MyClass {
private int _size;
private int _version;
public Clone(MyClass obj) {
this._size = obj._size;
this._version = obj._version;
}
}
Why does C# allow direct access to private members of an object?
It is so by definition:-
https://docs.microsoft.com/en-us/dot...ywords/private
Private members are accessible only within the body of the class or the struct in which they are declared
As long as you're accessing the instance of the same class from within the body of the class itself, it is allowed. There really is no sensible reason for this not to be the case and it eases some potential frustrations. For example, try writing a Clone method for a VB6 class module that doesn't allow you to set it's state through a public interface. You would be forced to expose it's internals when you may not necessarily want to.
Originally Posted by SearchingDataOnly
Closure?
Nothing so exciting. Scoping rules within the same compilation unit(dll, exe etc) are really just as illusions. The compiler only pretends it cannot see private members and refuses to compile when you try to access them externally. The intellisense is also in on this conspiracy, opting to not list private members outside of the class. In other words, all it takes to implement private access modifiers is for the compiler to refuse to compile your code when you don't play along with it's pretense.
-
Jul 5th, 2022, 08:41 AM
#21
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by wqweto
Only own class private members i.e. a method (private or not) in a class is able to access private members of the same class through a reference (of the same class).
This is the reason why this._size works in first place -- this is a reference of the same class as the method's own class :-))
Thanks for your reply, wqweto.
Under normal circumstances, the access rights of the member variables of the class should refer to "the access rights of the member variables of the instance of the class at runtime", not the access rights in the code window. However, since the C# compiler and documentation really have to interpret it in its own way, we can only accept it. In contrast, VB6's approach is more scientific, but inconvenient and inflexible.
Originally Posted by wqweto
Edit: So now you started cross-posting in multiple subforums here and annoy members of both ones -- not very clever. . .
There is a reason why the same question is being asked in different sub-forums. When this question was asked on the .NET forums, the question was purely a C# question. When this question was asked on the VB6 forum, it was a VB6 related question:
(1) This question is in addition to the question in post#1, which makes a comparison of the access rights of class members in C# and VB6.
(2) This question seems to indicate that VB6 does dynamic compilation in the code window, which doesn't seem to be the case for the C#-IDE (VisualStudio.NET).
(3) This problem is the same as the one in post#1, causing a lot of trouble for my code conversion work (C# to VB6), and I want to find a good solution.
Last edited by SearchingDataOnly; Jul 5th, 2022 at 08:44 AM.
-
Jul 5th, 2022, 08:49 AM
#22
Thread Starter
Frenzied Member
Re: Some unreasonable restrictions in VB6
Originally Posted by Niya
Note that this isn't true of VB6 though.
It is so by definition:-
https://docs.microsoft.com/en-us/dot...ywords/private
As long as you're accessing the instance of the same class from within the body of the class itself, it is allowed. There really is no sensible reason for this not to be the case and it eases some potential frustrations. For example, try writing a Clone method for a VB6 class module that doesn't allow you to set it's state through a public interface. You would be forced to expose it's internals when you may not necessarily want to.
Thank you, Niya. Yes, the C# approach is more convenient and flexible. But as in my reply above:
Under normal circumstances, the access rights of the member variables of the class should refer to "the access rights of the member variables of the instance of the class at runtime", not the access rights in the code window. However, since the C# compiler and documentation really have to interpret it in its own way, we can only accept it. In contrast, VB6's approach is more scientific, but inconvenient and inflexible.
-
Jul 5th, 2022, 12:28 PM
#23
Re: Some unreasonable restrictions in VB6
vb does not have private variables.
Code:
'-------------------- class1 ------------------------------------
Private a As Long
Private b As Long
Sub showMe()
MsgBox "a=" & Hex(a) & " b=" & Hex(b)
End Sub
Private Sub Class_Initialize()
a = &H11223344
b = &H55667788
End Sub
'----------------------- form1 ---------------------------------------
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal pDest As Long, ByVal pSrc As Long, ByVal ByteLen As Long)
Private Sub Form_Load()
Dim c As New Class1
c.showMe
SetPrivateLng c, &H34, &HAABBCCDD
SetPrivateLng c, &H38, &H99887766
c.showMe
End Sub
Sub SetPrivateLng(obj As Object, offset As Long, value As Long)
Dim o As Long
o = ObjPtr(obj) + offset
CopyMemory ByVal o, ByVal VarPtr(value), 4
End Sub
-
Jul 5th, 2022, 12:32 PM
#24
Re: Some unreasonable restrictions in VB6
Originally Posted by dz32
vb does not have private variables.
Code:
'-------------------- class1 ------------------------------------
Private a As Long
Private b As Long
Sub showMe()
MsgBox "a=" & Hex(a) & " b=" & Hex(b)
End Sub
Private Sub Class_Initialize()
a = &H11223344
b = &H55667788
End Sub
'----------------------- form1 ---------------------------------------
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByVal pDest As Long, ByVal pSrc As Long, ByVal ByteLen As Long)
Private Sub Form_Load()
Dim c As New Class1
c.showMe
SetPrivateLng c, &H34, &HAABBCCDD
SetPrivateLng c, &H38, &H99887766
c.showMe
End Sub
Sub SetPrivateLng(obj As Object, offset As Long, value As Long)
Dim o As Long
o = ObjPtr(obj) + offset
CopyMemory ByVal o, ByVal VarPtr(value), 4
End Sub
That isn't proving that VB doesn't have private variables, it is proving that it is possible to change the contents of memory directly. Obviously if you know where in memory a variable is being held you can change the contents.
-
Jul 5th, 2022, 12:37 PM
#25
Re: Some unreasonable restrictions in VB6
Originally Posted by PlausiblyDamp
That isn't proving that VB doesn't have private variables, it is proving that it is possible to change the contents of memory directly. Obviously if you know where in memory a variable is being held you can change the contents.
Yeah, I was thinking the same thing above. Basically, if we're willing to hack enough, we can change anything we like. But that just ignores the whole idea of scoping and lifetime. Niya talked about the compiler (and Intellisense) "conspiring" to make Private variables out of Friend variables. But, virtually by definition, that's what Private variables are.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Jul 5th, 2022, 01:10 PM
#26
Re: Some unreasonable restrictions in VB6
Originally Posted by dz32
vb does not have private variables.
You can also hack the memory in .Net to do this. In addition to this, reflection can also be used to access private members in .Net. It's also possible to do these things in C and C++. This is why I said private members are really just illusions. Private members are only private because your tools like the compiler and IDE conspire to hide them from you when you try to access them outside of their proper scope.
-
Jul 5th, 2022, 07:49 PM
#27
Re: Some unreasonable restrictions in VB6
All your vars are belong to us
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|