How to access class members without New
Author |
Message |
Torben Du #1 / 13
|
How to access class members without New
How do I make a class I can use without first having to create a instance with New: class test sub test() end sub end class sub main test.test end sub Regards Torben
|
Wed, 28 Jul 2004 16:30:16 GMT |
|
|
avex #2 / 13
|
How to access class members without New
See in Documentation about "Shared Members". avex
|
Wed, 28 Jul 2004 19:37:45 GMT |
|
|
Armin Zingle #3 / 13
|
How to access class members without New
Quote: > How do I make a class I can use without first having to create a > instance with New: > class test > sub test() > end sub > end class > sub main > test.test > end sub
You can create shared methods: class test Shared sub test() end sub end class In shared methods you can only access other class members that are shared as well. Armin
|
Wed, 28 Jul 2004 19:23:54 GMT |
|
|
Jonathan Alle #4 / 13
|
How to access class members without New
If all the methods are going to be Shared, use a Module instead. -- Jonathan Allen .Net Wish List Site: http://jonathan.cloverlink.com/
Quote:
> > How do I make a class I can use without first having to create a > > instance with New: > > class test > > sub test() > > end sub > > end class > > sub main > > test.test > > end sub > You can create shared methods: > class test > Shared sub test() > end sub > end class > In shared methods you can only access other class members that are shared > as well. > Armin
|
Thu, 29 Jul 2004 03:14:58 GMT |
|
|
Armin Zingle #5 / 13
|
How to access class members without New
Quote: > If all the methods are going to be Shared, use a Module instead.
Well, some people say, you don't need Modules anymore because there are shared members now. :-) Armin
|
Thu, 29 Jul 2004 03:35:12 GMT |
|
|
Jonathan Alle #6 / 13
|
How to access class members without New
True, but those people also think that shared variables are not globals. -- Jonathan Allen
Quote:
> > If all the methods are going to be Shared, use a Module instead. > Well, some people say, you don't need Modules anymore because there are > shared members now. :-) > Armin
|
Thu, 29 Jul 2004 09:24:02 GMT |
|
|
Armin Zingle #7 / 13
|
How to access class members without New
Quote: > True, but those people also think that shared variables are not > globals.
Globals can be accessed without a qualifier. So I wouldn't call shared members global. I prefer shared members because they are not globals. Well, globals in modules are not a real "problem" as long as they are unambiguous, i.e. no other module contains the same identifier. In this case, I can refer to it just using it's name (g_Var = 7). The problem is: As soon as another module is added and it contains the same global variable name, all references to the variable in the first module are not unambiguous anymore, I get a compiler error and have to add the module name in front (Module1.g_Var = 7). Using shared members I'm forced to do that right from the start. Armin Quote: > > > If all the methods are going to be Shared, use a Module > > > instead. > > Well, some people say, you don't need Modules anymore because > > there are shared members now. :-)
|
Thu, 29 Jul 2004 19:13:46 GMT |
|
|
Jay B. Harlow [MVP - Outlook #8 / 13
|
How to access class members without New
Armin, With VB.NET one can import a class, and the shared members are now at global scope! Import System.Math Allows me to use 'Cos' over 'Math.Cos' For 'data' I tend to prefer to qualify and actually hide behind methods (subs, functions or properties) for functions (like Math) I prefer not to qualify, as overloading should get me the version I want... Just a thought Jay
Quote:
> > True, but those people also think that shared variables are not > > globals. > Globals can be accessed without a qualifier. So I wouldn't call shared > members global. > I prefer shared members because they are not globals. Well, globals in > modules are not a real "problem" as long as they are unambiguous, i.e. no > other module contains the same identifier. In this case, I can refer to it > just using it's name (g_Var = 7). The problem is: As soon as another module > is added and it contains the same global variable name, all references to > the variable in the first module are not unambiguous anymore, I get a > compiler error and have to add the module name in front (Module1.g_Var = 7). > Using shared members I'm forced to do that right from the start. > Armin > > > > If all the methods are going to be Shared, use a Module > > > > instead. > > > Well, some people say, you don't need Modules anymore because > > > there are shared members now. :-)
|
Thu, 29 Jul 2004 22:35:31 GMT |
|
|
Armin Zingle #9 / 13
|
How to access class members without New
Quote: > Armin, > With VB.NET one can import a class, and the shared members are > now at global scope!
You're right. I haven't noticed that importing classes is just as possible as importing namespaces. But that's not the default behavior. In Modules, public members have global scope by default. Quote: > Import System.Math > Allows me to use 'Cos' over 'Math.Cos' > For 'data' I tend to prefer to qualify and actually hide behind methods > (subs, functions or properties) for functions (like Math) I prefer not to > qualify, as overloading should get me the version I want...
I agree. Despite, I don't think a shared member of imported classes is global by definition. Let's have a look at the following statements: 1. Global means, the member can be accessed without a qualifier in the *entire* project. 2. I think we are in agreement with the fact that one and the same shared member can be called either global or not - not both at the same time. 3. Whenever you import the class, as you say, it's shared members are global. 4. When a project has multiple files and you import a class in only one of the files then the member is "global" in one module, not in the others. That would be inconsistent with 2. and that's the reason why I don't call them global - they are imported and can be accessed without a modifier. Of course, you could import the class in all files or in the project's options, but the case study above shows that importing itself doesn't put the shared members to the global scope. If that would be the case, importing in one file were enough. I think so, I don't know... Armin
|
Fri, 30 Jul 2004 00:23:31 GMT |
|
|
Jay B. Harlow [MVP - Outlook #10 / 13
|
How to access class members without New
Armin, You are correct, global scope for that file. I tend to think of Global at a file level, but I agree with Global at a project level also.. Of course you can put Import System.Math in Project - Imports. Which then would make it global for all files... I suspect that VB.NET is implicitly doing this for modules, but that is hard to say ;-) At least this is the effect a Module has... Just a thought Jay
Quote:
> > Armin, > > With VB.NET one can import a class, and the shared members are > > now at global scope! > You're right. I haven't noticed that importing classes is just as possible > as importing namespaces. But that's not the default behavior. In Modules, > public members have global scope by default. > > Import System.Math > > Allows me to use 'Cos' over 'Math.Cos' > > For 'data' I tend to prefer to qualify and actually hide behind methods > > (subs, functions or properties) for functions (like Math) I prefer not to > > qualify, as overloading should get me the version I want... > I agree. Despite, I don't think a shared member of imported classes is > global by definition. Let's have a look at the following statements: > 1. Global means, the member can be accessed without a qualifier in the > *entire* project. > 2. I think we are in agreement with the fact that one and the same shared > member can be called either global or not - not both at the same time. > 3. Whenever you import the class, as you say, it's shared members are > global. > 4. When a project has multiple files and you import a class in only one of > the files then the member is "global" in one module, not in the others. > That would be inconsistent with 2. and that's the reason why I don't call > them global - they are imported and can be accessed without a modifier. > Of course, you could import the class in all files or in the project's > options, but the case study above shows that importing itself doesn't put > the shared members to the global scope. If that would be the case, importing > in one file were enough. > I think so, I don't know... > Armin
|
Fri, 30 Jul 2004 01:21:39 GMT |
|
|
Armin Zingle #11 / 13
|
How to access class members without New
Quote: > You are correct, global scope for that file. I tend to think of > Global at a file level, but I agree with Global at a project > level also.. > Of course you can put Import System.Math in Project - Imports. > Which then would make it global for all files... I suspect that > VB.NET is implicitly doing this for modules, but that is hard to > say ;-) At least this is the effect a Module has...
"global scope for that file" - not really! ;-)) Armin
|
Fri, 30 Jul 2004 01:31:24 GMT |
|
|
Jonathan Alle #12 / 13
|
How to access class members without New
Quote: > Globals can be accessed without a qualifier. So I wouldn't call shared > members global.
The definition of a global variable is "a variable than can be accessed globally". The fact that its name includes some dots does not change anything. Consider these two constants... System_Math_Pi System.Math.Pi Both can be accessed from anywhere in the program, so both are by definition global. The fact that one uses dots while the other uses underscores not withstanding. Remember, the first globals were referred to by memory addresses, not identifiers. Quote: > Well, globals in > modules are not a real "problem" as long as they are unambiguous, i.e. no > other module contains the same identifier.
That has nothing to do with the global vs. non-global issue. It is entirely a issue of whether or not modules should be imported by default. (Which, by the way, would make an interesting debate.) -- Jonathan Allen .Net Wish List Site: http://jonathan.cloverlink.com/
Quote:
> > True, but those people also think that shared variables are not > > globals. > Globals can be accessed without a qualifier. So I wouldn't call shared > members global. > I prefer shared members because they are not globals. Well, globals in > modules are not a real "problem" as long as they are unambiguous, i.e. no > other module contains the same identifier. In this case, I can refer to it > just using it's name (g_Var = 7). The problem is: As soon as another module > is added and it contains the same global variable name, all references to > the variable in the first module are not unambiguous anymore, I get a > compiler error and have to add the module name in front (Module1.g_Var = 7). > Using shared members I'm forced to do that right from the start. > Armin > > > > If all the methods are going to be Shared, use a Module > > > > instead. > > > Well, some people say, you don't need Modules anymore because > > > there are shared members now. :-)
|
Fri, 30 Jul 2004 08:24:37 GMT |
|
|
Armin Zingle #13 / 13
|
How to access class members without New
Quote: > > Globals can be accessed without a qualifier. So I wouldn't > > call shared members global. > The definition of a global variable is "a variable than can be > accessed globally". The fact that its name includes some dots > does not change anything. Consider these two constants... > System_Math_Pi > System.Math.Pi > Both can be accessed from anywhere in the program, so both are > by definition global. The fact that one uses dots while the > other uses underscores not withstanding. Remember, the first > globals were referred to by memory addresses, not identifiers.
I could agree with this approach, too. The remaining difference I see between shared members and globals in modules, is the fact that globals _can_ be accessed without a qualifier as long as they are unambiguous. Being forced to use a qualifier with public module variables is because of the resolution of _ambiguity_ not because they belong to a class and therefore _always_ have to be accessed using a qualifier. But that's my personal opinion. I'd be interested in the "official" definition - if your's isn't the real one already. :-) Quote: > > Well, globals in > > modules are not a real "problem" as long as they are > > unambiguous, i.e. no other module contains the same identifier. > That has nothing to do with the global vs. non-global issue.
No it hasn't, I gave the reason why I prefer shared members. Quote: > It > is entirely a issue of whether or not modules should be imported > by default. (Which, by the way, would make an interesting debate.)
They don't have to be (and aren't) imported because they are globals. ;-) Well, your defintion "a variable than can be accessed globally" is something I'll think about - and it seems to be more correct than mine... Armin
|
Fri, 30 Jul 2004 19:01:47 GMT |
|
|
|