Req10: share variables in method bodies

[This post is part of a series, "wish-list for future versions of VB"]


VB's "static variables" are a powerful and useful time-saver. They declare a variable with a one-off initialization which is shared amongst all invocations of a instance's method. For example, here's how you might declare a lazy singleton-per-instance:

    Public ReadOnly Property Engine As AnalysisEngine


            Static _engine As AnalysisEngine = AnalysisEngine.ExpensiveCreateFunction()

            Return _engine

        End Get

    End Property

Without static variables, people have to code the same thing manually, and they usually get it wrong (the error in this case is that it's not thread-safe):

    private AnalysisEngine _engine;

    public AnalysisEngine Engine




            return _engine ?? (_engine = AnalysisEngine.ExpensiveCreateFunction());




IDEA: Call them "shared variables" instead of "static variables". The grounds for this idea is that they are "shared between all invocations of an instance's method".


IDEA: Allow "shared per delegate" variables inside a lambda. VB already has the notion of static variables that are "shared between all invocations of an instance's method". It should also introduce a new notion, lambda-shared variables, that are "shared between every invocation of a given delegate",

        Dim g = Function()

                    Shared y As Integer = 2 ' shared amongst all invocations of this particular delegate


                    y += 1

                End Function



Provisional evaluation from VB team: Too confusing. Currently, "shared" unambiguously means "shared between all instances of a class". Static variables are not the same (unless they happen to be declared in a shared method). The lambda idea might be powerful but it's also too confusing. Someone reading your code shouldn't need the language-spec to hand just to understand which flavour of "shared" you're talking about.



        Static x As Integer = 1




Comments (6)

  1. Jonathan Allen says:

    The use case I really want to see is missing.

       Public Property Engine As AnalysisEngine

           Static _engine As AnalysisEngine


               Return _engine

           End Get


                ‘validate the new value

                _engine = Value

                ‘update any related properties

           End Set

       End Property

    The purpose of this syntax is to create a visibility even lower than "private". This way developers don’t accidentally modify "_engine" directly instead of going through the property.

  2. Dzonny says:

    I must say that I use Static local variable once a year or so and I’m quite happy with the Static keyword. One enhancement to to Static locals can be Shared Static making Static variable in instance method share its value across all instances of class the method is defined in. Since I use Static variables rarely this is more theoretical than practical idea from me.

    Static variables in lambdas: In theory everything that is allowed inside normal method should be allowed in multiline lambda. Practical use of it – I don’t know.

  3. Kevin Ryall says:

    It hardly seems worth changing the term (especially considering how rarely it’s used), but I do agree with Jonathan that being able to declare it with ‘property’ scope would be fantastic.

    Actually this is something I’ve always wanted – being able to declare any variable at the property level so it was accessible in the getter and setter but nowhere else would be fantastic – it’s something I have a ‘requirement’ for in almost every class I write. It seems like exactly the kind of thing VB should be doing – layering useful abstractions on top of the basic CLRT functionality.

    Maybe you have this planned for a future post though?

  4. Kyralessa says:

    I don’t know about Shared variables, but what I *would* like to see is the ability to declare a class as Shared, analogous to declaring a class as static in C#.  I know that using a Module is sort of the same, but it feels weird to me.

  5. Mark Hurd says:

    Don't like the head idea — agree with VB Team's assessment — but I do like Jonathan Allen's concept and I'd like an attribute or keyword on Modules to remove their automatic availability within a namespace rather than Kyralessa's Shared Class (although because of the analogue in C#, I wouldn't mind both — and I would think they would be identical behaviour. except you couldn't define Extension methods in a Shared Class).

  6. weitzhandler says:

    The thing of first idea is that C# assignment returns the assigned value.

    Since VB assignment and comparison operator is the same, this cannot be achieved.

Skip to main content