RE: Vb.net Modules or classes
Hi Tom, is it quiet in here or is my email on the fritz? Modules were weird and unclear abstractions in the old VB days that irritated and confused me. They still do, so whenever I make a new VB project I delete the Module and I create classes. I'm probably biased here because I come from a C/C++/Java background in the 90s. I'm a bit rusty on this, but can VB boffins confirm that a Module is similar to a static/Shared class of methods, but you see an unqualified flattened view of what they contain? Can someone also confirm that the concept of a Module is meaningless to the CLR? I'd run with your feeling on this that Modules are wrong. My console apps always have a class with a static/Shared Main method, which seems natural to me, not overkill. Cheers, Greg Ps. I recommend that you put all of the core functionality of what your apps do into a library and consider the Console app just a thin wrapper around that functionality. That way you can create Forms apps, services, etc that wrap the functionality. Pps. No coding over 0.05 or with a hangover.
RE: Vb.net Modules or classes
Greg Over the years, there have been some discussions on this, eg Joel Spolksky at http://tinyurl.com/26x7xg5 - and Microsoft does have some words in several places (I haven't chased them up). Erik Meier's explanations might be worth looking for. The joelonsoftware discussion is from 2006, and goes into the VB6/VBA origins of the idea of modules. A module is just a class where Shared is implicitly understood for each member, and the module name does not need to be supplied when the members are used. I'd agree that classes should be used, and to your approach to immediately delete the Module1 when a VB.NET project is first created. I would guess (Bill McCarthy would know better than I) that the CLI is ignorant of Module because the compiler transmogrifies to classes or equivalent. It's often said that Module was a kludge or aid and inducement for VB6/VBA people to transition to VB.NET. _ Ian Thomas Victoria Park, Western Australia _ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Sunday, 6 June 2010 3:19 PM To: 'ozDotNet' Subject: RE: Vb.net Modules or classes Hi Tom, is it quiet in here or is my email on the fritz? Modules were weird and unclear abstractions in the old VB days that irritated and confused me. They still do, so whenever I make a new VB project I delete the Module and I create classes. I'm probably biased here because I come from a C/C++/Java background in the 90s. I'm a bit rusty on this, but can VB boffins confirm that a Module is similar to a static/Shared class of methods, but you see an unqualified flattened view of what they contain? Can someone also confirm that the concept of a Module is meaningless to the CLR? I'd run with your feeling on this that Modules are wrong. My console apps always have a class with a static/Shared Main method, which seems natural to me, not overkill. Cheers, Greg Ps. I recommend that you put all of the core functionality of what your apps do into a library and consider the Console app just a thin wrapper around that functionality. That way you can create Forms apps, services, etc that wrap the functionality. Pps. No coding over 0.05 or with a hangover.
RE: Vb.net Modules or classes
Hi Greg, Ian, all As Ian says a Module is a Shared class. In C# a similar concept is a static class which I think they introduced in Visual C# 2005 or maybe it was 2008. VB's implementation is basically the same but there is also an implicit namespace import inside a project such that the module name is not needed. This is similar to importing a class name (VB only), eg: Class Foo Shared Sub Bar() ' End Sub End Class Then elsewhere in another code file Imports ConsoleApplication1.Foo Class X Sub test() Bar() ' Foo.Bar() can be written as Bar() End Sub End Class Apart from the global namespace magic, they are basically Shared (aka static in C#) classes. I think the main uses for them are for application entry points, hence forcing the code all to be Shared in there (which is the case), and more importantly for extension methods. |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Ian Thomas |Sent: Sunday, 6 June 2010 6:53 PM |To: 'ozDotNet' |Subject: RE: Vb.net Modules or classes | |Greg | |Over the years, there have been some discussions on this, eg Joel Spolksky at |http://tinyurl.com/26x7xg5 - and Microsoft does have some words in several |places (I haven't chased them up). | |Erik Meier's explanations might be worth looking for. | |The joelonsoftware discussion is from 2006, and goes into the VB6/VBA origins |of the idea of modules. | |A module is just a class where Shared is implicitly understood for each |member, and the module name does not need to be supplied when the |members are used. | |I'd agree that classes should be used, and to your approach to immediately |delete the Module1 when a VB.NET project is first created. | |I would guess (Bill McCarthy would know better than I) that the CLI is ignorant |of Module because the compiler transmogrifies to classes or equivalent. It's |often said that Module was a kludge or aid and inducement for VB6/VBA |people to transition to VB.NET. | | | |Ian Thomas |Victoria Park, Western Australia | | | |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Greg Keogh |Sent: Sunday, 6 June 2010 3:19 PM |To: 'ozDotNet' |Subject: RE: Vb.net Modules or classes | | | |Hi Tom, is it quiet in here or is my email on the fritz? | | | |Modules were weird and unclear abstractions in the old VB days that irritated |and confused me. They still do, so whenever I make a new VB project I delete |the Module and I create classes. I'm probably biased here because I come from |a C/C++/Java background in the 90s. I'm a bit rusty on this, but can VB boffins |confirm that a Module is similar to a static/Shared class of methods, but you |see an unqualified flattened view of what they contain? Can someone also |confirm that the concept of a Module is meaningless to the CLR? | | | |I'd run with your feeling on this that Modules are wrong. My console apps |always have a class with a static/Shared Main method, which seems natural to |me, not overkill. | | | |Cheers, | |Greg | | | |Ps. I recommend that you put all of the core functionality of what your apps do |into a library and consider the Console app just a thin wrapper around that |functionality. That way you can create Forms apps, services, etc that wrap the |functionality. | | | |Pps. No coding over 0.05 or with a hangover.
RE: Vb.net Modules or classes
It is interesting to read the VB Reference (MSDN or VB Developer Center) on the Class and the Module statements. Class: http://msdn.microsoft.com/en-US/library/wa0hwf23(v=VS.80).aspx Module: http://msdn.microsoft.com/en-us/library/aaxss7da(v=VS.80).aspx In particular, there is a small section in each on Classes and Modules - pointing out the similarities, and the important differences. This is for 3 different areas: terminology, shared members, and object orientation. Tom: If you're continuing to use Module, then there are important sections on Rules (Modifiers, Inheritance, Default property) and Behavior (Access Level, Scope, Qualification). And I would read both the links above, and then (from the Remarks section under the Class statement) jump to 5 of the links there. It's pretty obvious which are important. Ian Thomas Victoria Park, Western Australia -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Bill McCarthy Sent: Sunday, 6 June 2010 5:14 PM To: 'ozDotNet' Subject: RE: Vb.net Modules or classes Hi Greg, Ian, all As Ian says a Module is a Shared class. In C# a similar concept is a static class which I think they introduced in Visual C# 2005 or maybe it was 2008. VB's implementation is basically the same but there is also an implicit namespace import inside a project such that the module name is not needed. This is similar to importing a class name (VB only), eg: Class Foo Shared Sub Bar() ' End Sub End Class Then elsewhere in another code file Imports ConsoleApplication1.Foo Class X Sub test() Bar() ' Foo.Bar() can be written as Bar() End Sub End Class Apart from the global namespace magic, they are basically Shared (aka static in C#) classes. I think the main uses for them are for application entry points, hence forcing the code all to be Shared in there (which is the case), and more importantly for extension methods. |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Ian Thomas |Sent: Sunday, 6 June 2010 6:53 PM |To: 'ozDotNet' |Subject: RE: Vb.net Modules or classes | |Greg | |Over the years, there have been some discussions on this, eg Joel Spolksky at |http://tinyurl.com/26x7xg5 - and Microsoft does have some words in several |places (I haven't chased them up). | |Erik Meier's explanations might be worth looking for. | |The joelonsoftware discussion is from 2006, and goes into the VB6/VBA origins |of the idea of modules. | |A module is just a class where Shared is implicitly understood for each |member, and the module name does not need to be supplied when the |members are used. | |I'd agree that classes should be used, and to your approach to immediately |delete the Module1 when a VB.NET project is first created. | |I would guess (Bill McCarthy would know better than I) that the CLI is ignorant |of Module because the compiler transmogrifies to classes or equivalent. It's |often said that Module was a kludge or aid and inducement for VB6/VBA |people to transition to VB.NET. | | | |Ian Thomas |Victoria Park, Western Australia | | | |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Greg Keogh |Sent: Sunday, 6 June 2010 3:19 PM |To: 'ozDotNet' |Subject: RE: Vb.net Modules or classes | | | |Hi Tom, is it quiet in here or is my email on the fritz? | | | |Modules were weird and unclear abstractions in the old VB days that irritated |and confused me. They still do, so whenever I make a new VB project I delete |the Module and I create classes. I'm probably biased here because I come from |a C/C++/Java background in the 90s. I'm a bit rusty on this, but can VB boffins |confirm that a Module is similar to a static/Shared class of methods, but you |see an unqualified flattened view of what they contain? Can someone also |confirm that the concept of a Module is meaningless to the CLR? | | | |I'd run with your feeling on this that Modules are wrong. My console apps |always have a class with a static/Shared Main method, which seems natural to |me, not overkill. | | | |Cheers, | |Greg | | | |Ps. I recommend that you put all of the core functionality of what your apps do |into a library and consider the Console app just a thin wrapper around that |functionality. That way you can create Forms apps, services, etc that wrap the |functionality. | | | |Pps. No coding over 0.05 or with a hangover.
RE: Vb.net Modules or classes
Chaps, I think we've answered Tom's question in a way, eventually, I hope. He was suspicious of using Modules, and you've confirmed my suspicions that Modules are aliases for static classes that don't need to be qualified. No other .NET compliant language I know of hides what's going on underneath with a Module concept (except maybe F# where by default your methods go into one big anonymous class). I reckon you should avoid Modules, they always seemed a bit weird to me. Everyone recognises the word class. Greg
Re: Vb.net Modules or classes
Cheers guys, very helpful. On Sun, Jun 6, 2010 at 8:19 PM, Greg Keogh g...@mira.net wrote: Aha! Here’s the statement that sums it all up with legal clarity: http://msdn.microsoft.com/en-us/library/7825002w(v=VS.80).aspx *This means that variables in a standard module are effectively global variables because they are visible from anywhere in your project, and they exist for the life of the program.*** The defence (or prosecution) rests. Greg
Re: Vb.net Modules or classes
Gday dotnetters, Ever since I switched to vb.net i find im using Modules more and more, rarely creating classes, particularly at the entry point into a few utility console apps im working on. This definitely feels wrong, is it just bad design? Should i be learning OO design again? As an example say Im rewriting msbuild or similar tool, i can see myself just creating a single method in a Module and that'l be it. Is that bad? what if it is all i need? Should i create a class with a single Run method? Seems overkill Look forward to some responses, perhaps Im hungover :) From here : http://weblogs.asp.net/alex_papadimoulis/archive/2004/06/17/158295.aspx It seems that modules are just some sort of static-method-like thing. And while I completely disagree with the example in that blog post, for a VB.NET programmer that may be useful. I agree with his conclusion: do it if it feels good. Regarding writing an application that consists entirely of a Run method. Well, sure, if it only does one (very short) thing. But when it starts to do more you'll naturally end up with a nicer design as a result of implementing it correctly. -- silky http://www.programmingbranch.com/
