what is the difference between a Field and a Propery

  • Thread starter Thread starter Mark Kamoski
  • Start date Start date
M

Mark Kamoski

Hi Everyone--

Please help.

What is the difference between a Field and a Property?

Here is the context.

In the VS.NET 2002 documentation, in the "String Members" section, we have
the following...

....

Public Fields

....

Public Properties

....

....so, what is the difference?

In particular, I am noticing the String.Empty field, which is read-only.

Why isn't this simply a read-only Property?

Which leads one to think that there IS a difference between a Field and a
Property, but it is not clear to me what that difference is.

Is there a catch here?

That sums up my inquiry.

Please advise.

Thank you.

--Mark
 
Mark Kamoski said:
What is the difference between a Field and a Property?

Here is the context.

In the VS.NET 2002 documentation, in the "String Members" section, we
have the following...

...

Public Fields

...

Public Properties

...

...so, what is the difference?

It's explained in the VB.Net docs.

Public Field As Integer 'Field

Public Property Prop() As Integer 'Property
Get
End Get
Set
End Set
End Property
In particular, I am noticing the String.Empty field, which is
read-only.

Why isn't this simply a read-only Property?

A Field IS simpler:

'Field:
Public Shared Readonly Empty As String = ""

'Property:
Public Shared Readonly Property Empty() As String
Get
End Get
End property
 
Hi Mark,

Class SomeObject
Private ValueAsAField As Integer

Public Property ValueAsAProperty() As Integer
Get
Return ValueAsAField
End Get
Set
If Value < 0 Then Value = 0
ValueAsAField = Value
End Set
End Property
'More code follows which uses ValueAsAField
'perhaps in string handling or array access.
: : :
End Class

A Field is an area of memory within an object that stores some
information. That's all it does. All it <can> do.

A Property is, in its simplest form, a routine which guards access to a
corresponding field. The example above for instance won't allow negative
numbers to be stored but will set it to the minimum of zero. If the Field were
Public, the user of the object could set ValueAsAField to -1 which would
presumably cause problems later, eg in accessing an array item.

A Public Field allows direct access to the data - the caller simply plucks
the value out - while a Property always requires extra code to be run and acts
(for a Private Field) as a gate-keeper.

If you have a Public Field there is no point having a Property. If you
change you mind about it being Public, you can rename it, make it Private and
create a Property with the original name. This will then do checking or
whatever.

String.Empty is a constant. As it will never change its value, it doesn't
need any Property to guard it. Whether it is implemented as a Field or a Const
is another question.

Regards,
Fergus
 
Hi Fergus--

Thank you very much for your thoughts. They help to clear things up.

BTW, it seems that String.Empty is NOT actually a real Constant in the
sense that one cannot write...

Public Const MyStringConstant As String = String.Empty

....because the IDE complains that a "Constant expression is required".

But, I understand the gist of what you are saying in that the value of
String.Empty is constant (lowercase emphasis) and unchanging.

I guess what made things less than clear was the terminology-- in that
Property is a keyword and "Field" is not. And so on. I thought there was
something fundamental that I had missed, such a "Field" being a special
type of Property or something. It is good to know that that is not the
case.

Thank you very much.

--Mark


Hi Mark,

Class SomeObject
Private ValueAsAField As Integer

Public Property ValueAsAProperty() As Integer
Get
Return ValueAsAField
End Get
Set
If Value < 0 Then Value = 0
ValueAsAField = Value
End Set
End Property
'More code follows which uses ValueAsAField
'perhaps in string handling or array access.
: : :
End Class

A Field is an area of memory within an object that stores some
information. That's all it does. All it <can> do.

A Property is, in its simplest form, a routine which guards access to a
corresponding field. The example above for instance won't allow negative
numbers to be stored but will set it to the minimum of zero. If the Field
were
Public, the user of the object could set ValueAsAField to -1 which would
presumably cause problems later, eg in accessing an array item.

A Public Field allows direct access to the data - the caller simply
plucks
the value out - while a Property always requires extra code to be run and
acts
(for a Private Field) as a gate-keeper.

If you have a Public Field there is no point having a Property. If you
change you mind about it being Public, you can rename it, make it Private
and
create a Property with the original name. This will then do checking or
whatever.

String.Empty is a constant. As it will never change its value, it
doesn't
need any Property to guard it. Whether it is implemented as a Field or a
Const
is another question.

Regards,
Fergus
 
Hi Mark,

You're welcome.

Lol, come back when you start reading about Asynchronous Delegates and
Reflection - documentation written for mind-readers - plenty of scope for
confusion.

The same applies to a lot of the documentation in between. ;-)

Regards,
Fergus
MVP [Windows Start button, Shutdown dialogue]
 
Fergus Cooney said:
Hi Mark,

You're welcome.

Lol, come back when you start reading about Asynchronous Delegates and
Reflection - documentation written for mind-readers - plenty of scope for
confusion.

YES!!!!!!!!!!!!!!!!!!!!!!!!!! THIS IS TRUE!

I didn't notice this before but at the bottom of the reflection documents
and delegate documents it says

"Requires version 1.1 Framework and PHD."

Missed that last part apparently.



The same applies to a lot of the documentation in between. ;-)

Regards,
Fergus
MVP [Windows Start button, Shutdown dialogue]
 
Back
Top