G
Guest
Is that true you can't have a static method in VB.NET?
Public Static Sub Initialize() -- ???
thanks
Mark
Public Static Sub Initialize() -- ???
thanks
Mark
M
Marina Levit [MVP]
You use the keyword 'Shared', but it has the same effect.
So you can have a static method, there is just no static keyword that you
can put in the function declaration.
So you can have a static method, there is just no static keyword that you
can put in the function declaration.
C
Cor Ligthert [MVP]
Mark,
Visual basic had not to do with old legacy names from C.
Therefore is there a name used which describes this better.
Public Shared Sub etc.
I hope this helps,
Cor
Visual basic had not to do with old legacy names from C.
Therefore is there a name used which describes this better.
Public Shared Sub etc.
I hope this helps,
Cor
G
Guest
Thanks!
Mark
Mark
Cor Ligthert said:
D
dgk
I think that you can't declare a class as shared, but if everything in
it is shared then the class is, in reality, shared. Please correct me
if I'm wrong on this.
M
Mythran
dgk said:
Well, in VB, you can...use Module...which, in turn, is a static class
Mythran
H
Herfried K. Wagner [MVP]
Cor Ligthert said:
Well said -- that's why we have our old BASIC legacy 'Static'
.
J
Jay B. Harlow [MVP - Outlook]
Mythran,
| Well, in VB, you can...use Module...which, in turn, is a static class
Unfortunately a Module has the added "annoyance"/"feature" of being
implicitly imported, where as C#'s static class needs to be explicitly
qualified.
If you like the convenience of implicit imported, then using a Module for a
static class is good, however I find needing to qualify the identifiers of a
static class to be more beneficial. As I then know where the identifier is
coming from.
For example:
Debug.WriteLine(...)
You know that the WriteLine is part of the Debug class, rather then:
WriteLine(...)
You don't know if WriteLine is part of System.Diagnostics.Debug,
System.Console, a base class, a Module, or something else...
I normally reserve Module's for truly global identifiers, such as math
functions. I see some benefit in having System.Math being a module, however
its easy enough to import System.Math to gain unqualified access to its
identifiers...
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
|
| | > On Tue, 21 Mar 2006 16:30:49 +0100, "Cor Ligthert [MVP]"
| >
| >>Mark,
| >>
| >>Visual basic had not to do with old legacy names from C.
| >>
| >>Therefore is there a name used which describes this better.
| >>
| >>Public Shared Sub etc.
| >>
| >>I hope this helps,
| >>
| >>Cor
| >>
| > I think that you can't declare a class as shared, but if everything in
| > it is shared then the class is, in reality, shared. Please correct me
| > if I'm wrong on this.
|
| Well, in VB, you can...use Module...which, in turn, is a static class
|
| Mythran
|
| Well, in VB, you can...use Module...which, in turn, is a static class
Unfortunately a Module has the added "annoyance"/"feature" of being
implicitly imported, where as C#'s static class needs to be explicitly
qualified.
If you like the convenience of implicit imported, then using a Module for a
static class is good, however I find needing to qualify the identifiers of a
static class to be more beneficial. As I then know where the identifier is
coming from.
For example:
Debug.WriteLine(...)
You know that the WriteLine is part of the Debug class, rather then:
WriteLine(...)
You don't know if WriteLine is part of System.Diagnostics.Debug,
System.Console, a base class, a Module, or something else...
I normally reserve Module's for truly global identifiers, such as math
functions. I see some benefit in having System.Math being a module, however
its easy enough to import System.Math to gain unqualified access to its
identifiers...
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
|
| | > On Tue, 21 Mar 2006 16:30:49 +0100, "Cor Ligthert [MVP]"
| >
| >>Mark,
| >>
| >>Visual basic had not to do with old legacy names from C.
| >>
| >>Therefore is there a name used which describes this better.
| >>
| >>Public Shared Sub etc.
| >>
| >>I hope this helps,
| >>
| >>Cor
| >>
| > I think that you can't declare a class as shared, but if everything in
| > it is shared then the class is, in reality, shared. Please correct me
| > if I'm wrong on this.
|
| Well, in VB, you can...use Module...which, in turn, is a static class
|
| Mythran
|
D
dgk
Mythran,
| Well, in VB, you can...use Module...which, in turn, is a static class
Unfortunately a Module has the added "annoyance"/"feature" of being
implicitly imported, where as C#'s static class needs to be explicitly
qualified.
If you like the convenience of implicit imported, then using a Module for a
static class is good, however I find needing to qualify the identifiers of a
static class to be more beneficial. As I then know where the identifier is
coming from.
For example:
Debug.WriteLine(...)
You know that the WriteLine is part of the Debug class, rather then:
WriteLine(...)
You don't know if WriteLine is part of System.Diagnostics.Debug,
System.Console, a base class, a Module, or something else...
I normally reserve Module's for truly global identifiers, such as math
functions. I see some benefit in having System.Math being a module, however
its easy enough to import System.Math to gain unqualified access to its
identifiers...
Then using Imports is bad because you don't know where the
object/method/whatever is actually coming from. And that's true.
Whenever I start playing with someone else's code I start commenting
out the Imports. I love seeing those little blue squigglies appear.
J
Jay B. Harlow [MVP - Outlook]
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
Yes Imports "hide" where identifiers are coming from...
However! You at least need to explicitly list the Imports at the top of each
source file, or at the project level. Whereas a Module is implicitly
imported at the project level...
Project level imports & now project level import aliases can also be both
good & "bad".
Generally I find:
| > Debug.WriteLine(...)
To be easier to read then:
| > System.Diagnostics.Debug.WriteLine(...)
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
| On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
|
| >Mythran,
| >| Well, in VB, you can...use Module...which, in turn, is a static class
| >Unfortunately a Module has the added "annoyance"/"feature" of being
| >implicitly imported, where as C#'s static class needs to be explicitly
| >qualified.
| >
| >If you like the convenience of implicit imported, then using a Module for
a
| >static class is good, however I find needing to qualify the identifiers
of a
| >static class to be more beneficial. As I then know where the identifier
is
| >coming from.
| >
| >For example:
| >
| > Debug.WriteLine(...)
| >
| >You know that the WriteLine is part of the Debug class, rather then:
| >
| > WriteLine(...)
| >
| >You don't know if WriteLine is part of System.Diagnostics.Debug,
| >System.Console, a base class, a Module, or something else...
| >
| >I normally reserve Module's for truly global identifiers, such as math
| >functions. I see some benefit in having System.Math being a module,
however
| >its easy enough to import System.Math to gain unqualified access to its
| >identifiers...
|
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
| Whenever I start playing with someone else's code I start commenting
| out the Imports. I love seeing those little blue squigglies appear.
| object/method/whatever is actually coming from. And that's true.
Yes Imports "hide" where identifiers are coming from...
However! You at least need to explicitly list the Imports at the top of each
source file, or at the project level. Whereas a Module is implicitly
imported at the project level...
Project level imports & now project level import aliases can also be both
good & "bad".
Generally I find:
| > Debug.WriteLine(...)
To be easier to read then:
| > System.Diagnostics.Debug.WriteLine(...)
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
| On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
|
| >Mythran,
| >| Well, in VB, you can...use Module...which, in turn, is a static class
| >Unfortunately a Module has the added "annoyance"/"feature" of being
| >implicitly imported, where as C#'s static class needs to be explicitly
| >qualified.
| >
| >If you like the convenience of implicit imported, then using a Module for
a
| >static class is good, however I find needing to qualify the identifiers
of a
| >static class to be more beneficial. As I then know where the identifier
is
| >coming from.
| >
| >For example:
| >
| > Debug.WriteLine(...)
| >
| >You know that the WriteLine is part of the Debug class, rather then:
| >
| > WriteLine(...)
| >
| >You don't know if WriteLine is part of System.Diagnostics.Debug,
| >System.Console, a base class, a Module, or something else...
| >
| >I normally reserve Module's for truly global identifiers, such as math
| >functions. I see some benefit in having System.Math being a module,
however
| >its easy enough to import System.Math to gain unqualified access to its
| >identifiers...
|
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
| Whenever I start playing with someone else's code I start commenting
| out the Imports. I love seeing those little blue squigglies appear.
C
Cor Ligthert [MVP]
dgk,
You would than in my opinion be consequent and remove as well all imports
from the project property file.
Would be a very strange looking program than.
In version 2003
Select project properties and look than to imports
Just my thought,
Cor
You would than in my opinion be consequent and remove as well all imports
from the project property file.
Would be a very strange looking program than.
In version 2003
Select project properties and look than to imports
Just my thought,
Cor
J
Jay B. Harlow [MVP - Outlook]
I should add to my previous day's post, that the likely hood (at least in my
code) of "overloading" an method is greater then "overloading" a type.
For example there would probably be only a single "Debug" type in my
application (solution) (across all namespaces), where as there maybe many
"Write" methods unique to any numbers of types. (for example Equals,
ToString). <sidenote> I use namespaces more for organization then to allow
me to have 2 types with the same name in different namespaces, as chances
are if they have the same name they have the same function... However this
is not always true, for example the Person domain object and the Person web
page or Person windows form, although I normally use Person, PersonPage &
PersonForm for the types themselves...</sidenote>
Hence qualifying a method with a type name (Debug.WriteLine) is generally
more beneficial then qualifying a type name with a namespace
(System.Diagnostics.Debug)... The Imports System.Diagnostics (at either the
file or project level) simply saves typing System.Diagnostics every place I
need to use the Debug type.
While the qualifying Debug ensures that I can introduce a WriteLine method
in my type without it interfering with calling the Debug.WriteLine method...
For a "better" example of the problems the implicit import causes try
calling VB.Left (Microsoft.VisualBasic.Strings.Left) function in a form.
Because Form has a Left property you cannot call the Left function
unqualified... <sidenote>This is one place where I will use an import alias.
"Imports VB = Microsoft.VisualBasic" which allows me to call
VB.Left...</sidenote>
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
| On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
|
| >Mythran,
| >| Well, in VB, you can...use Module...which, in turn, is a static class
| >Unfortunately a Module has the added "annoyance"/"feature" of being
| >implicitly imported, where as C#'s static class needs to be explicitly
| >qualified.
| >
| >If you like the convenience of implicit imported, then using a Module for
a
| >static class is good, however I find needing to qualify the identifiers
of a
| >static class to be more beneficial. As I then know where the identifier
is
| >coming from.
| >
| >For example:
| >
| > Debug.WriteLine(...)
| >
| >You know that the WriteLine is part of the Debug class, rather then:
| >
| > WriteLine(...)
| >
| >You don't know if WriteLine is part of System.Diagnostics.Debug,
| >System.Console, a base class, a Module, or something else...
| >
| >I normally reserve Module's for truly global identifiers, such as math
| >functions. I see some benefit in having System.Math being a module,
however
| >its easy enough to import System.Math to gain unqualified access to its
| >identifiers...
|
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
| Whenever I start playing with someone else's code I start commenting
| out the Imports. I love seeing those little blue squigglies appear.
code) of "overloading" an method is greater then "overloading" a type.
For example there would probably be only a single "Debug" type in my
application (solution) (across all namespaces), where as there maybe many
"Write" methods unique to any numbers of types. (for example Equals,
ToString). <sidenote> I use namespaces more for organization then to allow
me to have 2 types with the same name in different namespaces, as chances
are if they have the same name they have the same function... However this
is not always true, for example the Person domain object and the Person web
page or Person windows form, although I normally use Person, PersonPage &
PersonForm for the types themselves...</sidenote>
Hence qualifying a method with a type name (Debug.WriteLine) is generally
more beneficial then qualifying a type name with a namespace
(System.Diagnostics.Debug)... The Imports System.Diagnostics (at either the
file or project level) simply saves typing System.Diagnostics every place I
need to use the Debug type.
While the qualifying Debug ensures that I can introduce a WriteLine method
in my type without it interfering with calling the Debug.WriteLine method...
For a "better" example of the problems the implicit import causes try
calling VB.Left (Microsoft.VisualBasic.Strings.Left) function in a form.
Because Form has a Left property you cannot call the Left function
unqualified... <sidenote>This is one place where I will use an import alias.
"Imports VB = Microsoft.VisualBasic" which allows me to call
VB.Left...</sidenote>
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
| On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
|
| >Mythran,
| >| Well, in VB, you can...use Module...which, in turn, is a static class
| >Unfortunately a Module has the added "annoyance"/"feature" of being
| >implicitly imported, where as C#'s static class needs to be explicitly
| >qualified.
| >
| >If you like the convenience of implicit imported, then using a Module for
a
| >static class is good, however I find needing to qualify the identifiers
of a
| >static class to be more beneficial. As I then know where the identifier
is
| >coming from.
| >
| >For example:
| >
| > Debug.WriteLine(...)
| >
| >You know that the WriteLine is part of the Debug class, rather then:
| >
| > WriteLine(...)
| >
| >You don't know if WriteLine is part of System.Diagnostics.Debug,
| >System.Console, a base class, a Module, or something else...
| >
| >I normally reserve Module's for truly global identifiers, such as math
| >functions. I see some benefit in having System.Math being a module,
however
| >its easy enough to import System.Math to gain unqualified access to its
| >identifiers...
|
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
| Whenever I start playing with someone else's code I start commenting
| out the Imports. I love seeing those little blue squigglies appear.