What is the effect of having constructor in a module?

  • Thread starter Thread starter Peter
  • Start date Start date
P

Peter

Does constructor New applicable to a module? What happen when a member of
the module test is accessed?

public module Test

sub new()
....
end sub
..
..
..
end module
 
Hi Peter,

That's a Shared constructor. You cannot create instances of a Module because
it is a static class.
The constructor will be called before the first time anything in the module
is used
 
Hi Peter,

That's a Shared constructor. You cannot create instances of a Module
because it is a static class.
The constructor will be called before the first time anything in the
module is used

I'm curious why modules are still included in VB.NET? Are they a bit
redundant when there are classes? I never really saw the point of modules
except for legacy VB programmers?
 
Spam Catcher said:
I'm curious why modules are still included in VB.NET? Are they a bit
redundant when there are classes? I never really saw the point of modules
except for legacy VB programmers?

yes and no ;) Modules are the same as a static lass is in C# (for the most
part). In both languages they are useful. The thing I don't like about
VB's modules is they do a global import of the module name, akin to writing
Imports Application.Module1 everywhere which means that the Module's methods
show up in intellisense unqualified.
In the long term, I'd like to see us be able to use Shared on a class
construct.

Of course, in VB9, when dealing with Extension methods they need to be
defined in a Module (our only Shared Class construct). This can be
advantageous too because then the extension methods show automatically
without you needing to import the module's name.
 
Spam Catcher said:
I'm curious why modules are still included in VB.NET? Are they a bit
redundant when there are classes? I never really saw the point of modules
except for legacy VB programmers?

Modules are a language construct for loose grouping of things which belong
to each other but do not form an instantiateable entity. Take the Visual
Basic Runtime Library as an example. The 'Interaction' module provides
functions like 'MsgBox' and 'InputBox', the 'String' module contains
functions used to deal with strings, ...
 
Bill McCarthy said:
yes and no ;) Modules are the same as a static lass is in C# (for the
most part). In both languages they are useful. The thing I don't like
about VB's modules is they do a global import of the module name, akin to
writing Imports Application.Module1 everywhere which means that the
Module's methods show up in intellisense unqualified.
In the long term, I'd like to see us be able to use Shared on a class
construct.

Bill,

You can use Shared on a class constructor...

Public Class Test
Shared Sub New()

End Sub
End Class

- OR -

Do you mean on the class declaration line?

Public Shared Class Test
Public Sub New()

End Sub
End Class

??

Mythran
 
yes and no ;) Modules are the same as a static lass is in C# (for the
most part). In both languages they are useful. The thing I don't
like about VB's modules is they do a global import of the module name,
akin to writing Imports Application.Module1 everywhere which means
that the Module's methods show up in intellisense unqualified.
In the long term, I'd like to see us be able to use Shared on a class
construct.

You can have a shared constructor which essentially turns a class into a
static object. So I really don't see the value of modules :-)
 
Hi Bill,

If I understand correctly, module members are shared and most of them are
public.
Also, a module will be compiled into a class internally. Since module
cannot be
instantiated, is there any reason to put the constructor in a module? The
reason that I'm thinking about the constructor since I'm trying to create a
List() and I don't want to have coding to call a module sub to create the
list. I'm thinking about put the declaration and initialization of the list
inside the New() sub of the module.
 
Hi Mythran,

Can you explain the effect of your coding? I'm quite new to VB.net coding.

Thanks,

Peter
 
Hi Herfried,

If I have things which don't belong to each other but I need all of them to
be available across an application or assembly without instantiation, should
I create one module for all or one module for each thing?
 
Peter said:
If I have things which don't belong to each other but I need all of them
to
be available across an application or assembly without instantiation,
should
I create one module for all or one module for each thing?

It depends on the exact situation (size of the project, project type, type
of "things"). Note that there are many more solutions than a module for
this purpose, such as a class with shared members or a class implementing
the singleton design pattern. Each of this solution has its advantages and
disadvantages.
 
Peter said:
If I understand correctly, module members are shared and most of them are
public.
Also, a module will be compiled into a class internally. Since module
cannot be
instantiated, is there any reason to put the constructor in a module?

Yes. It's basically the same as a 'Shared Sub New' in a class which has
only shared members. This constructor can be used to initialize data for
the modules members or the class' shared members. Sample:

\\\
Public Module Foo
Private m_Cache As New List(Of Goo)()

Sub New()

' Fill 'm_Cache' here.
...
End Sub

Public Function GetGoo(...) As Goo

' Take cached item from 'm_Cache' and return it.
...
End Function
End Module
///
 
Hi Herfried,

So, the usage of a Sub New() in a module is actually same as a Shared Sub
New() in a class. The main difference I believe will be that the Sub New()
in a module will be called once when a reference to any member of the module
is executed first time while the Shared Sub New() will be called when the
class is instantiated first time.
 
The
reason that I'm thinking about the constructor since I'm trying to create a
List() and I don't want to have coding to call a module sub to create the
list. I'm thinking about put the declaration and initialization of the list
inside the New() sub of the module.

If all you need to do is implement a complex initializer, an alternative to
Sub New is an initializer function like the following:

Public Module zzz
Public Xxx As Date = XxxInitializer
Private Function XxxInitializer() As Date
Dim y As Date
' ... code to make y goes here
Return y
End Function
End Module

Private XxxInitalizer is not visible outside the module, and the initializer
is called automatically (you don't have to do it yourself). Also, FxCop
warns about static initializers (module sub new, class shared sub new), so
you would remove this somewhat dubious FxCop complaint.
 
Peter said:
So, the usage of a Sub New() in a module is actually same as a Shared Sub
New() in a class. The main difference I believe will be that the Sub
New()
in a module will be called once when a reference to any member of the
module
is executed first time while the Shared Sub New() will be called when the
class is instantiated first time.

A 'Shared Sub New' of a class will also be called if the first access is an
access to a shared member.
 
Hi Mythran,

I was referring to the class declaration:

Public Shared Class Test

Which today you can't do in VB.NET
 
Spam Catcher said:
You can have a shared constructor which essentially turns a class into a
static object. So I really don't see the value of modules :-)

The Shared Sub New doesn't make the class static. To effectively make a
class static you need to mark it as NotInheritable, include a Private Sub
New and no other instance constructors, and ensure that every field, method
and property in the class is marked as Shared.
 
Bill,

What is a static class?

Static means that it is fixed to a certain point in memory.
While VB is only for NT which uses relocatable memory addresses, is this a
term from pre history.
(And therefore is the term static, to avoid breaking changes, stayed as name
for variables which holds there values although they go out of scope, in
fact it are global created variables inside a method)

(The same as probably the Static class in C# which is in fact a module)

However you can use Shared classes in VB, which means that you can use the
class shared to instance it as objects on many places.

Cor
 
Peter,

A Shared Class and a module are almost the same; to keep it compatible with
earlier versions means however that the module has some in fact for modern
times not wanted behaviour with the Dims, which are globaly created. They
are public in the project. However as you avoid the dim on global level of a
module, then you have the same effect as a shared class. (Although I use in
this case the module, which is in my opinion much clearer then)

A shared class is in fact the same as beer without alcohol (a typical Dutch
invention), it sells nice, however is of course no beer.

A shared class is a module, which is like that created in the main stack of
a program, it has nothing to do with classes.

A class describes a type which can be instanced as an object to residence on
the managed heap.

However there is a strong loby to let VB to get more and more the bad
behaviours of C# which it has from legancy from C++. So AFAIK you can use
now in VB 2008 a Shared class which has methods which can be instanced, this
is probably to make everything more confusing. I don't see any reason to use
that.

Cor
 
Cor,

There is no such thing as a Shared Class in VB. That was the point of my
comment. There is Module but that has other side effects as has already
been discussed.
 
Back
Top