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.
