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.