Learning VB!

I need help this time :slight_smile: Can someone explain to me why VB lets you access a sub inside a module directly! Is there a keyword to stop it from doing so?

Namespace Test
    Module MyMod
        Sub MySub()

        End Sub
    End Module
End Namespace
Public Module Module1

    Sub Main()
        Test.MySub() ' I do not like this but it compiles!
        Test.MyMod.MySub() ' now this is how it should be.
        ' .....

I used classes instead and things look better now :slight_smile:

In VB a Sub, by default, is declared Public therefore can be called from anywhere in your application that has access to the module, class, or structure in which you defined it.

@ Gus - I try to define everything either private or public. I would be better if VB forced this, but it does not

Imports GT = Gadgeteer
Imports GTM = Gadgeteer.Modules

Namespace GadgeteerApp1
    Partial Public Class Program
        Dim Classier As New Classy

        Public Sub ProgramStarted()
            Debug.Print("Program Started")
        End Sub
    End Class

    Partial Public Class Classy
        Public Sub Hello()
            ' this is visible outside the class
        End Sub

        Private Sub NeverHeardOfYou()
            ' this is not visible
        End Sub
    End Class
End Namespace

@ Gus - that’s the way it works. All the members inside Module become global, i. e. you can access them from anywhere and you don’t need to use its name as a prefix (you can use Shared classes instead if you want the opposite). Also, all members within Module become Shared.

I thought I will never see this day coming, but here we go - @ Gus is learning VB :slight_smile:

@ iamin - but you didn’t ask yourself why :wink:

1 Like

@ Gus - Why? :whistle:

I can think of two options - provide VB examples in NETMF/Gadgeteer books, teach very young pupils (you talked about a project a few days ago) - either of which is overoptimistic, I guess. So, yes, I want to know why are you interested in VB.

The question is “Why does VB act this way?”

@ Blue Hair Bob - The simple answer: it is designed to act this way. For more in-depth answer, I guess, you need to ask creators of VB to find out why they did it this way and not any other way.

So, the answer is “Because it does”. Or, just “because”. Or, “Just because”

When I was a kid, that wasn’t ever good enough to satisfy me. Still isn’t. But that’s just me. Why? Well, inquiring minds want to know.

@ Blue Hair Bob - Who could better know a definitive answer to this question other than creators of VB?

Well, I also liked (and still like) to ask the “why” questions. But not every time. For example, why is my keyboard black and not gray, why is Start button on the left by default and not on the right, why has FEZ Hydra this specific name and not some other name and so on :slight_smile:

The key here is to remember the motivation behind VB.NET was to support the migration of VB6 and earlier developers to the .NET platform, therefore a Module in VB.NET was designed to act and feel like a Module in original VB. Internally the VB compiler spits out a static class for the module and all methods defined in the module are defined as static members of the class. The last piece of syntactic sugar the compiler adds is to automatically infer the class name when invoking the module member.

Some interesting points

  1. Interestingly .NET also has the concept of modules within an assembly, but this has nothing at all to do with VB.NET modules and VS does not support modules in assemblies.

  2. C# 6 will have (unless this changed???) using static which will import static class members so that you do not have to explicitly reference the class name every time you invoke a static member on the class. Similar syntactic sugar as VB.NET provides except that the using will be explicit rather than implicit as in VB.NET