|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
static methodsIs that true you can't have a static method in VB.NET?
Public Static Sub Initialize() -- ??? thanks Mark 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. Show quoteHide quote "Mark" <M***@discussions.microsoft.com> wrote in message news:A73565BC-BF92-43E5-A6F0-C312D1DBC580@microsoft.com... > Is that true you can't have a static method in VB.NET? > Public Static Sub Initialize() -- ??? > > thanks > Mark 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 Show quoteHide quote "Mark" <M***@discussions.microsoft.com> schreef in bericht news:A73565BC-BF92-43E5-A6F0-C312D1DBC580@microsoft.com... > Is that true you can't have a static method in VB.NET? > Public Static Sub Initialize() -- ??? > > thanks > Mark Thanks!
Mark Show quoteHide quote "Cor Ligthert [MVP]" wrote: > 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 > > "Mark" <M***@discussions.microsoft.com> schreef in bericht > news:A73565BC-BF92-43E5-A6F0-C312D1DBC580@microsoft.com... > > Is that true you can't have a static method in VB.NET? > > Public Static Sub Initialize() -- ??? > > > > thanks > > Mark > > > On Tue, 21 Mar 2006 16:30:49 +0100, "Cor Ligthert [MVP]"
<notmyfirstn***@planet.nl> wrote: >Mark, I think that you can't declare a class as shared, but if everything in> >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 > it is shared then the class is, in reality, shared. Please correct me if I'm wrong on this.
Show quote
Hide quote
"dgk" <d**@somewhere.com> wrote in message Well, in VB, you can...use Module...which, in turn, is a static class :)news:o5f0229538npgskjt9k7ngkgaeeahn12mc@4ax.com... > On Tue, 21 Mar 2006 16:30:49 +0100, "Cor Ligthert [MVP]" > <notmyfirstn***@planet.nl> wrote: > >>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. Mythran 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... -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "Mythran" <kip_potter@hotmail.comREMOVETRAIL> wrote in message news:%23W8poWRTGHA.5828@TK2MSFTNGP14.phx.gbl... | | "dgk" <d**@somewhere.com> wrote in message | news:o5f0229538npgskjt9k7ngkgaeeahn12mc@4ax.com... | > On Tue, 21 Mar 2006 16:30:49 +0100, "Cor Ligthert [MVP]" | > <notmyfirstn***@planet.nl> wrote: | > | >>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 | On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
<Jay_Harlow_***@tsbradley.net> wrote: Show quoteHide quote >Mythran, Then using Imports is bad because you don't know where the>| 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... 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. | Then using Imports is bad because you don't know where the Yes Imports "hide" where identifiers are coming from...| object/method/whatever is actually coming from. And that's true. 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(...) -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "dgk" <d**@somewhere.com> wrote in message news:cnj222dveq8a6elc0k8pda2jrs1kkl76bo@4ax.com... | On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]" | <Jay_Harlow_***@tsbradley.net> wrote: | | >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. 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 Show quoteHide quote "dgk" <d**@somewhere.com> schreef in bericht news:cnj222dveq8a6elc0k8pda2jrs1kkl76bo@4ax.com... > On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]" > <Jay_Harlow_***@tsbradley.net> wrote: > >>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. 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> -- Show quoteHide quoteHope this helps Jay [MVP - Outlook] ..NET Application Architect, Enthusiast, & Evangelist T.S. Bradley - http://www.tsbradley.net "dgk" <d**@somewhere.com> wrote in message news:cnj222dveq8a6elc0k8pda2jrs1kkl76bo@4ax.com... | On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]" | <Jay_Harlow_***@tsbradley.net> wrote: | | >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. "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> schrieb: Well said -- that's why we have our old BASIC legacy 'Static' :-).> Visual basic had not to do with old legacy names from C. -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> |
|||||||||||||||||||||||
Other interesting topics