Are there Shared Classes in VB.NET 2.0?

M

Mike_R

Junior Contributor
Joined
Oct 20, 2003
Messages
316
Location
NYC
Hi guys...

Are there "Shared" Classes in VB.NET 2.0 to match C#'s "Static" classes? Or did they not bother in VB.NET because VB.NET has Modules?

The thing is though, a Static Class (enforcing that there are no instance members) is not quite the same as a Module, which is essentially a Static class plus an implicit global imports statement...

Is the solution, then, that I have to continue creating a Private New() contructor for VB.NET classes that I wish to enforce as Static? Using the 'Shared' keyword in front of a Class definition does not seem to be accepted by the compiler.

Anyway, I'm guessing that this is in fact the "lay of the land", but I was wondering if anyone else had some thoughts on this...

Thanks in advance! :),
Mike
 
As far as I can tell VB doesn't get them. I only stumbled across this fact myself the other day, I'd always just assumed they existed as I can't see a single reason why they wouldn't be implemented...
 
Yeah, I just hit on this too and was surprised... And I agree with you, one would think it would be easy for them to do this. (And so would an 'out' keyword, for that matter.. :p)

Thanks PD :)
 
In terms of IL, a static class is declared as both abstract (can not be instantiated) and sealed (can not be derived, preventing any possibility of being instantiated). If you check a static C# class in Reflector, you will see that both these attributes are tagged onto the class. A Module is, on the other hand, defined as internal (Friend) and sealed. I tried declaring a C# class as abtract sealed and tried declaring a VB class as MustInherit NotInheritable and both resulted in a compile time error. I guess you are just out of luck. Microsoft must have just decided that a Module would suffice.
 
Heh, thanks for trying 'MustInherit NotIheritable'. :) Sounds ridiculous, but, well, it was worth a shot. It's no less sensible than a private constructor, if you think about it, but a private constructor is allowed, so that's the only way I guess. On the other hand, it is interesting that an abstract class can actually have its shared methods called directly; astract classes feel like an incomplete beast, but their static members are fully formed and callable. Cool. :cool:

The IL on a Module is interesting, I think a Module might default to being Friend/Internal, but I'm pretty sure that it can be public. I think that the Microsoft.VisualBasic.Constants namespace is a public module in order for constants such as 'vbCrLf' can be accessible without the need for a long namespace path or imports statement. Kinda neat. But for the most part, a static class is a better idea, I think...
 
marble_eater said:
In terms of IL, a static class is declared as both abstract (can not be instantiated) and sealed (can not be derived, preventing any possibility of being instantiated). If you check a static C# class in Reflector, you will see that both these attributes are tagged onto the class. A Module is, on the other hand, defined as internal (Friend) and sealed. I tried declaring a C# class as abtract sealed and tried declaring a VB class as MustInherit NotInheritable and both resulted in a compile time error. I guess you are just out of luck. Microsoft must have just decided that a Module would suffice.
Click to expand...

C# "static" does not mean abstract and sealed, but sealed and non-instantiatable (i.e., private constructor).
The VB module is close enough to the C# static class that there's no reason to have a "Shared" class.
 
No, static does not mean abstract and sealed. I did not say that. What I said is that when compiled to IL, static classes have the sealed and abstract attributes (without any constructor whatsoever defined). Effectively, a class that is sealed and abstract is the same as a class that is static because the only possible meaningful members are static members, so this was chosen as the IL representation of a C# static class.

The following is the disassembled IL of a static class:
Code: 
.[COLOR=Blue]class private [U]abstract[/U] auto ansi [U]sealed[/U] beforefieldinit[/COLOR] StaticClass
      [COLOR=Blue]extends[/COLOR] [COLOR=Green]object[/COLOR]
{
}

And, Mike, you are right. Friend is only the default accessibility modifier of the VB Module. Behaviorally, a VB Module is the same as a C# sealed class, with the exception of the automatic global import. In terms of its IL definition, though, a VB Module is more similar to what you are doing now. It is a sealed class with a private constructor.
[Edit]Just an afterthought: One might find it interesting that the rules of the .Net runtime would allow a VB module to instantiate itself. This is only prevented at compile-time by the VB compiler. This is not the case with the C# static (abstract/sealed) class.[/Edit]
 
Modules aren't very object oriented and since that is the, to be somewhat cyncial, buzz word of the decade (past few I suppose, really), objects such as classes and structs are preferred over nebulous clouds of global methods and data members. I think object oriented programming is a great thing, but there is a time, a place, and a need for every programming paradigm. With something that is considered non-standadard or discouraged you need to reflect a little harder on your project and design to determine if a module is really what you should use -- make a conscience decision about it, don't just fall into it. You should be doing this for all aspects of your design for that matter, but more so for things that go against convention or against something that is generally considered good practice.
 
I will admit that in the past I have used modules in the development of .NET projects, and still do - it's the only way that I can actually perform the task that I need to, which is to provide a particular universal class for all other classes of a certain type. I wont go into it here, but let's just say it's the only module and it works very efficiently and does not hugely breach readability issues.
 
Back
Top