Protected fields

[Andy_P]

With reference to the following link to MSDN titled 'Do not declare visible instance fields'...

http://msdn.microsoft.com/en-us/libr...41(VS.80).aspx

Externally visible refers to public, protected, and protected internal (Public, Protected, and Protected Friend in Visual Basic) accessibility levels.

Protected fields are also considered visible.

...I am a bit confused as to why fields defined as 'protected' in a class are considered to be externally 'visible'.

As I understand it, if you have an abstract class and a protected field defined within that class, that field can only be accessed by the containing class, and any classes derived from it. I agree that it is visible from classes other than the one it is defined in, but only derived classes. Isn't that the point of 'protected'?

The article suggests defining the field as 'private', and accessing it via a protected property.

This seems like an unnecessary step to me, but perhaps I am missing something. (Highly likely.)


Thoughts?

[syntaxeater]

Nope, not missing a thing. For the same reason you don't declare fields public, you don't declare them protected. While yes, they are only visible to derived objects, they are visible to anything deriving from it (single layer public).

4.0 has a new implementation to make the redundancy a little less... redundant:

Public Property MyProperty As string

This assumes a private string field "MyProperty" for you (during JIT).

Now the reason for all this? Fields are limiting and very much so. You can't bind to a field, fields are a pain in the arse to validate consistently, and they are not overrideable/overloadable (shadow works, but the value only exists when working with the derived class).

Binding - The following works:

Public Class myExample
        Private m_Value As string
        Public property Value as string
            Get
                Return m_value
            End Get
            Set(ByVal value As String)
                m_value = value
            End Set
        End Property
    End Class
 
    Private Sub Form1_Load( ByVal sender As System.Object,  ByVal e As System.EventArgs) Handles MyBase.Load
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="1"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="2"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="3"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="4"})
 
        Me.ComboBox1.DisplayMember = "Value"
    End Sub

This, however, does not:

Public Class myExample
        Public Value As string
    End Class
 
    Private Sub Form1_Load( ByVal sender As System.Object,  ByVal e As System.EventArgs) Handles MyBase.Load
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="1"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="2"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="3"})
        Me.ComboBox1.Items.Add(New myExample() with {.Value ="4"})
 
        Me.ComboBox1.DisplayMember = "Value"
    End Sub

[Andy_P]

Hmmm, ok, I definitely agree with the point about not making fields public, and on reflection I think I see the point is valid for protected also.

Interesting to see the new implementation in 4.0. I assume this does the same thing for protected properties also? (i.e. Defines a private field for you 'behind the scenes'.)

I'm using 2.0, so will not affect me, but interesting nonetheless.


Thanks for the reply.

[syntaxeater]

Interesting to see the new implementation in 4.0. I assume this does the same thing for protected properties also? (i.e. Defines a private field for you 'behind the scenes'.)

Yes, for the single line property - scope doesn't change the implementation.
From the "New Features in VB10" doc:

Auto-implemented Properties
Developers often need to create simple entity classes or containers for data, in which the properties defined follow a very simple structure:
Private _FirstName As String

Property FirstName() As String
Get
Return _FirstName
End Get
Set(ByVal value As String)
_FirstName = value
End Set
End Property

Auto-implemented properties provide a simple one-line way of expressing this concept:

Property ID() As Integer
Property FirstName() As String
Property LastName() As String

In this case the compiler will generate a backing field with the same name as the property, but with a preceding underscore. It will also fill in the property’s getter and setter.
Initializers can be used to give an auto-implemented property a default value (which gets set in the class’ constructor):
Property ID() As Integer = -1
Property SupplierList() As New List(Of Supplier)
Property OrderList() As New List(Of Order) With {.Capacity = 100}

<DefaultValue("-")>
Property Name() As String Implements ICustomer.Name

Auto-implemented properties cannot have parameters, nor can they be declared ReadOnly or WriteOnly.

[mendhak]

Implicit public properties/autoimplemented properties already exist in C# 2.0, it's just being made available to VB.NET in VB.NET 4.0.