Public variable not the same as using a property?

[dgk]

If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

[Armin Zingler]

"dgk" <dg*@somewhere. comschrieb

If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

No, it doesn't convert anything. The first is a public field, the second a
property.

Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

Probably a missing feature that it can not bind to public fields.
Armin

[PvdG42]

"dgk" <dg*@somewhere. comwrote in message
news:k8******** *************** *********@4ax.c om...

If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

From a design perspective, they are very different. And IMHO, you should
consider the difference.
If you declare the variable as public, you are giving unrestricted access to
that variable to code outside the class, thus exposing the variable to
potential corruption and breaking encapsulation. By declaring the variable
private, then supplying a public property in your class, you have the
opportunity and ability to control access to that variable by either not
providing a Set block, or by adding logic in the Set block that will
disallow illogical values.

[dgk]

On Fri, 14 Sep 2007 08:55:28 -0500, "PvdG42" <pv**@toadstool .edu>
wrote:

>"dgk" <dg*@somewhere. comwrote in message
news:k8******* *************** **********@4ax. com...

>If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

From a design perspective, they are very different. And IMHO, you should
consider the difference.
If you declare the variable as public, you are giving unrestricted access to
that variable to code outside the class, thus exposing the variable to
potential corruption and breaking encapsulation. By declaring the variable
private, then supplying a public property in your class, you have the
opportunity and ability to control access to that variable by either not
providing a Set block, or by adding logic in the Set block that will
disallow illogical values.

Well sure, but if you don't care what comes in or goes out, then it's
a lot cleaner to just declare a public variable. Also quicker to type.
One line instead of six or seven (even if using a snippet).

One of the things I don't like about VB is that Readonly on the
property. I mean, if there's no Set, then it's readonly. I'm sure they
did that for a reason but I can't figure out why.
Well, anyway, if you're planning on using Databind, don't use public
properties.

[\(O\)enone]

Terry wrote:

So maybe this is one of those subtle differences. I believe that
what you said was true for VB6, but obviously has changed.

This is one of the very few things that I actually preferred in VB6.

In VB5, if you created a public field and then at a later date decided you
needed to convert it to a public property, it would break binary
compatibility.

In VB6, this was changed so that the interface was identical between public
fields and properties. You could therefore create public fields in your
code, and if at a later time you realised you needed to convert them into
properties, you could just do it. Everything kept working and everyone was
happy.

Introducing the distinction between fields and properties in .NET has always
seemed like a backwards step to me. It means that if you want to safeguard
against the possibility of ever wanting to use a property in the future, you
need to code a property right from the start. The end result is dozens of
properties that do nothing more than set or retrieve the private variable
behind them.

That's a shame IMO.

--

(O)enone

[=?Utf-8?B?VGVycnk=?=]

Fortunatly, with code snippets, it is an easy thing to do. I have set up my
own snippet that always has a backing variable with an underscore followed by
the property name, so I only have to supply the name and type and that makes
it as easy as declaring a public variable (field).
--
Terry
"(O)enone" wrote:

Terry wrote:

So maybe this is one of those subtle differences. I believe that
what you said was true for VB6, but obviously has changed.

This is one of the very few things that I actually preferred in VB6.

In VB5, if you created a public field and then at a later date decided you
needed to convert it to a public property, it would break binary
compatibility.

In VB6, this was changed so that the interface was identical between public
fields and properties. You could therefore create public fields in your
code, and if at a later time you realised you needed to convert them into
properties, you could just do it. Everything kept working and everyone was
happy.

Introducing the distinction between fields and properties in .NET has always
seemed like a backwards step to me. It means that if you want to safeguard
against the possibility of ever wanting to use a property in the future, you
need to code a property right from the start. The end result is dozens of
properties that do nothing more than set or retrieve the private variable
behind them.

That's a shame IMO.

--

(O)enone

[dgk]

On Fri, 14 Sep 2007 12:18:01 -0700, Terry <Te****@nospam. nospam>
wrote:

>Fortunatly, with code snippets, it is an easy thing to do. I have set up my
own snippet that always has a backing variable with an underscore followed by
the property name, so I only have to supply the name and type and that makes
it as easy as declaring a public variable (field).

Yes, it is easy to do, although not as easy as just Public MyVar as
String. However, properties take up a lot more screen real estate than
a one line declaration. Four "fields" expand to thirty lines pretty
quickly.

Since the vast majority of my properties are string (and the default
snippet is integer) I set up my own that at least makes a string
property.

[Cor Ligthert[MVP]]

Armin,

Probably you know this, properties are optimezed by the runtime system in a
way that they act as fields (Not all that what we see in the debugger).

Cor

"Armin Zingler" <az*******@free net.deschreef in bericht
news:un******** ******@TK2MSFTN GP04.phx.gbl...

"dgk" <dg*@somewhere. comschrieb

>If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

No, it doesn't convert anything. The first is a public field, the second a
property.

>Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

Probably a missing feature that it can not bind to public fields.
Armin

[Cor Ligthert[MVP]]

dgk,

What do you want to ask when you have already your (incorrect) answers.

Cor

"dgk" <dg*@somewhere. comschreef in bericht
news:qn******** *************** *********@4ax.c om...

On Fri, 14 Sep 2007 08:55:28 -0500, "PvdG42" <pv**@toadstool .edu>
wrote:

>>"dgk" <dg*@somewhere. comwrote in message
news:k8****** *************** ***********@4ax .com...

>>If I have a class with a public variable, isn't this the same as a
private variable with a property? ie, isn't this:

Public Class MyTest
Public MyVar as String
End Class

the same as this:

Public Class MyTest
Private _MyVar as String
Property MyVar
Get
Return _MyVar
End Get
Set (byval value as String)
_MyVar = value
End Set
End Property
End Class
I always thought so, in fact, I thought that the complier converted
the first into the second.

Yet, when I try to databind a generic list of MyTest to a gridview
using the first syntax, it fails. When I use the second syntax it
succeeds.

Does anyone know why?

From a design perspective, they are very different. And IMHO, you should
consider the difference.
If you declare the variable as public, you are giving unrestricted access
to
that variable to code outside the class, thus exposing the variable to
potential corruption and breaking encapsulation. By declaring the variable
private, then supplying a public property in your class, you have the
opportunity and ability to control access to that variable by either not
providing a Set block, or by adding logic in the Set block that will
disallow illogical values.

Well sure, but if you don't care what comes in or goes out, then it's
a lot cleaner to just declare a public variable. Also quicker to type.
One line instead of six or seven (even if using a snippet).

One of the things I don't like about VB is that Readonly on the
property. I mean, if there's no Set, then it's readonly. I'm sure they
did that for a reason but I can't figure out why.
Well, anyway, if you're planning on using Databind, don't use public
properties.

[Armin Zingler]

"Cor Ligthert[MVP]" <no************ @planet.nlschri eb

Armin,

Probably you know this, properties are optimezed by the runtime
system in a way that they act as fields

Yes, but not in the debug version. I don't create overhead just because of
knowing that it might be optimized away or because tools ignore public
fields.

I fully agree with dgk. (his post from 17:10)

(Not all that what we see in
the debugger).

Pardon?
Armin