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
Get
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
{
get
{
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
Console.WriteLine(y)
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.
asdasd
Static x As Integer = 1
asdasd
adsad
Comments
Anonymous
February 14, 2010
The use case I really want to see is missing. Public Property Engine As AnalysisEngine Static _engine As AnalysisEngine Get Return _engine End Get Set '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.Anonymous
February 14, 2010
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.Anonymous
February 15, 2010
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?Anonymous
March 10, 2010
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.Anonymous
October 06, 2010
The comment has been removedAnonymous
January 11, 2011
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.