-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static
Property Variables
#195
Comments
I like "Implicit property backing fields #196" very much. This " Ye olde But now we have classes etc. Not sure how Finally, giving a |
I'm not sure that Just as an example, this code: Public Class Foo
Public Sub Bar()
Static meep As Integer = 1
meep = meep + 1
End Sub
End Class results in the following compiled code: Public Class Foo
Private $STATIC$Bar$2001$meep As Integer
Private $STATIC$Bar$2001$meep$Init As StaticLocalInitFlag
Public Sub Bar()
If Me.$STATIC$Bar$2001$meep$Init Is Nothing Then
Interlocked.CompareExchange(Of StaticLocalInitFlag)(Me.$STATIC$Bar$2001$meep$Init, New StaticLocalInitFlag(), Nothing)
End If
Dim flag As Boolean = False
Try
Monitor.Enter(Me.$STATIC$Bar$2001$meep$Init, flag)
If Me.$STATIC$Bar$2001$meep$Init.State = 0S Then
Me.$STATIC$Bar$2001$meep$Init.State = 2S
Me.$STATIC$Bar$2001$meep = 1
ElseIf Me.$STATIC$Bar$2001$meep$Init.State = 2S Then
Throw New IncompleteInitialization()
End If
Finally
Me.$STATIC$Bar$2001$meep$Init.State = 1S
If flag Then
Monitor.[Exit](Me.$STATIC$Bar$2001$meep$Init)
End If
End Try
Me.$STATIC$Bar$2001$meep += 1
End Sub
End Class If all that people are asking for is "fields scoped to a property", then all of the extra thread-safety seems unnecessary. So either you end up with this extra overhead because you have to use I'm not sure how practical this is, but what about another "accessor" in a property declaration where you can define the variables that are scoped to the getter and setter. Property P As T
Variables
Dim myVariable As T = 1
Static myStatic As T = 2
Const myConst As T = 3
End Variables
Get
Return myVariable
End Get
Set(value As T)
myVariable = value
End Set
End Property It would give you the full flexibility of using |
Before we go down this rabbit-hole, can someone explain why this "work-around" is so onerous?:
Or, what real advantage does #195 provide? |
I think the advantage is it would "pretend" to only allow the field to be modified inside the property, thus ensuring any event wiring isn't bypassed etc. Reflection, where allowed, would bypass this as a field is still a field. The other advantage is code organisation/ refactoring. If you delete the property P you have to still delete the field and vice versa. Having them next to each other makes that a bit easier but also messes up appearance of collapsed code. I like the idea, but would like the syntax to be exactly the same as if the field was declared outside the Property. Not "Static", but "Private" "Public", "Friend" and "Dim". I should be able to edit the code by simple drag and drop of fields into their property declaration or out. And if a field is Private or Dim, then if it is accessed outside the property I'd expect a compiler warning. |
Update: The 11/15/2017 LDM rejected this idea. In short, we didn't think it was worth special-casing fields. The existing scenario seems adequately addressed with fields not being private to a property. |
Some set of people have asked us to enable fields scoped to a property. VB already has
Static
local variables, which as effectively fields scoped to their containing method. For lazily computed read-only variables this already enables one to write code where the backing store of aReadOnly
property is entirely local to that property. We could extend this to come up with a syntax for property scoped fields:This works around a syntactic ambiguity with
Dim
sinceDim
could also be the start of a field declaration:We could still work around this without the special syntax with "statement" look-ahead, whereby the parser keeps accumulating field declarations until it hits either an accessor or something which can't be in a property. If it hits a property accessor it consumes all the field statements as its children. If it hits something else if closes itself and leaves all those field declarations "around" for the class to pick up as its children. This sounds a little messy but it's actually an extremely unlikely scenario to happen in practice. If, however, we elected to allow other modifiers like
Private
the scenario becomes more common, though still solvable. Either way, the multi-statement "look-ahead" isn't wasteful since those statements were going to be parsed as fields anyway. We don't need to throw away any work and re-parse.The text was updated successfully, but these errors were encountered: