-
Notifications
You must be signed in to change notification settings - Fork 66
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
Proposal: A compact Full ReadOnly Property #403
Comments
I can't see any issue with allowing this form, as it could be implemented through Public ReadOnly Property Content() string : Get : Return Foo() : End Get : End Property So we could then do Public ReadOnly Property Content() string : Return Foo() : End Property Which would reduce a lot of "simple" properties to single line implementations. |
While I have sympathy for the goal, I'm not convinced by the argument. Because I don't see how the use of I get my you might wonder if you're coming from a different language, and you don't yet know VB, but I don't see how in the VB world, Public ReadOnly Property Content() as String = Foo() could be read as anything other than Content being assigned the value of Foo(). Would a more VB-esque lambda/expression body style not look more like: Public ReadOnly Property Content() as String = Get Foo() ? |
@pricerc
This is the spirit that VB built on, you have a semi-natural language, but it is not verbose. Public ReadOnly Property Sum() string
Dim _sum = 0
For each .....
_sum+= .......
Next
Return _sum
End Property The block above is crying out loud that it is a |
There are good reasons why object-oriented languages have keywords for things like GETting and SETting properties. Even C# doesn't allow properties without get/set. I don't think removing those keywords enhances the language or will makes it easier for people in the future to understand. What you're proposing reminds me of the old VB6 days, when you'd have: ' Readonly Property
Public Property Get Sum As String
...
End Property
Private m_Name As String
Public Property Get Name As String
Name = m_Name
End Property
Public Property Let Name(Value As String)
m_Name = Value
End Property |
If I were to advocate for a change around property declarations, I'd vote for making the ReadOnly and WriteOnly modifiers optional (or inferred) - if there is no Set declared, then it's ReadOnly, if there's no Get declared, then it's WriteOnly. ' ReadOnly property
Property Foo() As String
Get
Return GetBar()
End Get
End Property Or ' ReadOnly property, Expression body style.
Property Foo() As String = Get Return GetBar()
|
Another reason: Public ReadOnly Property ViewName As String
Get
Return IndexView.CreateNew(Students, ViewData)
End Get
End Property Which I should be allowed to be written as: Public ReadOnly Property ViewName As String
Return IndexView.CreateNew(Students, ViewData)
End Property |
And to prove my point, try this: Property Test() As Integer = IncValue()
Dim value = 0
Function IncValue()
Return value + 1
End Function
Sub Main()
Console.WriteLine(Test) ' 1
Console.WriteLine(Test) ' 1
End Sub The Test property will always return 1, because it calls the IncValue only as an intila value, and stuc with this value! |
This is reasonable observation, one that has been made elsewhere in this repo. There is a whole issue related to expression-body syntax for properties: #61. If that's your goal, then this proposal is a duplicate of that one. But apart from that, with respect, the rest of your post just highlights basic 'rookie' mistakes that anyone can make when switching languages (which I also do all the time; I have both C# and VB projects that I'm working on at the moment), and forgetting how the language works. It doesn't mean that it's a problem with the language. |
@pricerc Public ReadOnly Property Sum() string
Dim _sum = 0
For each .....
_sum+= .......
Next
Return _sum
End Property
Surely it is. The language made fatal decision that forced us to use a another language, so it have to make every adjustment to prevent such incompatibility mistakes! |
It was not fatal, and I'd suggest to say so is very disparaging of the very, very smart people who have been designing these programming languages for years. VB and C# are different languages, and the only thing they need to share is the ability to use each other's (compiled) libraries. To put it bluntly: people getting the two confused is not the fault of either language, but of the users of the languages. As my late father always liked to tell me: "A poor workman always blames his tools". I don't find their 'mismatchings' confusing at all, because I recognise that they are different languages designed with slightly different goals in mind.
I was responding specifically to your message This is something different:
And I don't see the value is this at all. Other than not having to type "Get" (a whole three letters), what is the benefit? You are actually (as I mentioned earlier), basically advocating a (partial) return to the old VB6 way of declaring properties, and having several subtly different ways of doing the same thing: ' you're proposing:
Public ReadOnly Property Sum() As Double
Dim result As Double = 0
' do some stuff
Return result
End Property
' instead of this, which works fine.
Public ReadOnly Property Sum() As Double
Get
Dim result As Double = 0
' do some stuff
Return result
End Get
End Property
' and in VB6, it would have been:
Public Property Get Sum() as Double
Dim result As Double = 0
' do some stuff
Sum = result
End Property There was a conscious decision to move away from the VB6 style, and to put Get and Set into the same Property 'block', and I think that was a good idea. As I mentioned earlier in this thread, I'd support removing the requirement for ReadOnly and WriteOnly (as this can be inferred from the absence of Set or Get), but removing I would also suggest that your proposal (about removing |
I don't discuss this idea. It is still applied to read/write properties. I am speaking about unnecessary decorating block. It will not confuse the compiler to erase the Get block in this context. In fact we have erased Get and Set blocks along with the backing field and the compiler get it write!
|
I don't think 'shortest as possible' was ever a design goal for VB
I don't think that is useful on its own, if those lines come at the cost of ease-of-maintenance.
I don't think that typing less is a good design goal on its own. Long term maintainability is much more important.
Maybe, but I'm not sure that you and I will agree on what is easy to recognize in a glimpse. Which of these do you more quickly recognize as a property, as opposed to a function? (Ideally, you should use a blurred image to try this) Public Readonly Property FooProp As String
Get
Return "BAR"
End Get
End Property
Public Readonly Property FooProp2 As String
Return "BAR"
End Property
Public Shared Function FooFunc As String
Return "BAR"
End Function I know which 'Property' I find most obvious.
Possibly. But for now, the guidelines are:
I think your proposal falls short on at least three. In particular, it:
In this case, you're advocating for, in addition to the existing property definitions:
I think that adding these two new ways to do something that is already very simple, would have new users asking: "Why do we have three different ways of declaring properties?". |
These guidelines can be interpreted in different ways. Most new vb features since 2005 are consedered alternative ways to already existing syntax. By the way: |
Because properties are actually a special set of methods (Property Get is a special kind of Function, and Property Set is a special kind of Sub). The point being that a field does not have code associated with it, but a property does (even if you can't see it) I'm sure you know that VB just translates auto-implemented properties; from: Public Property Foo() As String into Private _foo As String
Public Property Foo() As String
Get
Return _foo
End Get
Set(Value As String)
_foo = Value
End Set
End Property C# does much the same, except that it uses a mangled name for the private (backing store) field. The compiler and runtime are then able to inject code into properties, which they can't do with fields, because fields are just bits of memory, but properties are bits of code. There's also some basis in object-oriented language design theory, where properties are the preferred interface to the outside world, and fields should really only be private or friend, and never public. |
Possibly, but they're not usually subtle. E.g. Auto-implemented properties are very different from full properties, not just a "subtly alternate syntax".
Yeah, one of the reasons I'm not a big fan of lambdas and anonymous methods. They look cool, but they can easily cause problems. It's an example of where more typing now helps with maintenance later. int Map() {
return DoSomething();
}
int Map {
get { return DoSomething(); }
} is much clearer. There are also places where using |
|
Proposal: A compact Full ReadOnly Property
Every time I get confused about the meaning of assigning an expression to auto implemented read-only property in VB: is it just an initial value that is only executed once, or will it be executed every time the property is called?!
Public ReadOnly Property Content() as String = Foo()
This is becfuase C# has = and => that makes the difference between the two meaning very cler!
So, I decide to write the full property:
I cal recall that there are proposals to add => to VB, but today, I have another suggestion: just get rid of
Get… end Get
:This shorter syntax has every info that has to tell and still in a VB style (without =>)!
And it can be perfect with a multiline body:
Likewise, and just for duality, the write-only property (which I never used) can get rid of the
Set End Set
and use the Value param directly (as it can be earased from Set End Set today and still be used)The text was updated successfully, but these errors were encountered: