Modules days numbered?

  • Thread starter Thread starter Zamdrist
  • Start date Start date
Z

Zamdrist

With as class and object oriented .Net is, is the concept of general
modules days numbered?

When did you last add a general module to your project, and why
wouldn't you have used a class instead?
 
You can create a class with Shared Methods and it behaves like a Module and
you can create a Module and it becomes a class with Shared Methods.

Try this tool http://www.red-gate.com/products/reflector/. This will give u
a better understanding of the inside implementation.

Regards,

Trevor Benedict
MCSD
 
Zamdrist said:
With as class and object oriented .Net is, is the concept of general
modules days numbered?

When did you last add a general module to your project, and why
wouldn't you have used a class instead?
Click to expand...

System.Math?
 
Actually, it does have to do with the subject of your post. This is how the
Reflector shows an example module decompiled.

Friend NotInheritable Class MyModule
' Methods
Public Shared Sub FooBar()
Public Shared Function Sqrt(ByVal x As Double) As Double
End Class
 
Then perhaps I worded my post wrongly.

There are Class Modules, and general modules.

If one writes a completely OO program in Visual Studio, would there be
a need for general modules...and therefore, given how OO .Net is, do
general modules become irrelevant, a could they in fact be removed as
a 'feature' from future versions of Visual Studio.
 
If one writes a completely OO program in Visual Studio, would there be
a need for general modules...and therefore, given how OO .Net is, do
general modules become irrelevant, a could they in fact be removed as
a 'feature' from future versions of Visual Studio.
Click to expand...

Strictly speaking, you mean "Visual Basic", not "Visual Studio" - it is
rather telling that a ground-up .NET language (i.e. C#) doesn't have the
concept of modules - just the facility to have a static class.

Ultimately they compile to the same thing; the biggest issue is
backwards compatibility. If the next version of VB didn't support them I
imagine there would be an outcry from the VB devs who use them.

Marc
 
Indeed, and my original thought is, the days of general modules in
VB.Net (as you rightly point out) are numbered, especially given
Microsoft's track record.
 
Marc Gravell said:
Strictly speaking, you mean "Visual Basic", not "Visual Studio" - it is
rather telling that a ground-up .NET language (i.e. C#)
Click to expand...

I'm not sure I would agree that C# is 'ground-up' .NET language. It makes a
number of concessions to C++ that I don't think a truely'green field'
language would have made. For example in VB one has to be explicit about
what methods are intended as implementations of which interface members.
However since C++ allowed such things happen implicitly and hence C# does
also. Personally the potential of unintended behaviour (an existing class
member can unintentionly become an implementation of a newly added interface
member) makes the explicit approach more desirable. VB language designers,
not having any inheritance baggage, choose a more explicit approach.

Why would a 'ground-up' .NET language choose to use a type called int
instead of Int32? Because it helps C++/Java devs.
 
Back
Top