Public variable not the same as using a property?

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?

"dgk" <dgk@somewhere.comschrieb

Quote:

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.

Quote:

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

"dgk" <dgk@somewhere.comwrote in message
news:k82le35h7tu7ap35tc23bpfr7gf32ordfi@4ax.com...

Quote:

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.

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

Quote:

>"dgk" <dgk@somewhere.comwrote in message
>news:k82le35h7tu7ap35tc23bpfr7gf32ordfi@4ax.com.. .

Quote:

>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.

Terry wrote:

Quote:

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

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:

Quote:

Terry wrote:

Quote:

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
>
>
>

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

Quote:

>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.

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.nospam@freenet.deschreef in bericht
news:un86$Rt9HHA.4712@TK2MSFTNGP04.phx.gbl...

Quote:

"dgk" <dgk@somewhere.comschrieb

Quote:

>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.
>

Quote:

>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

dgk,

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

Cor

"dgk" <dgk@somewhere.comschreef in bericht
news:qn8le3dj2alr17mrgjvmq1r22cmhavfa37@4ax.com...

Quote:

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

Quote:

>>"dgk" <dgk@somewhere.comwrote in message
>>news:k82le35h7tu7ap35tc23bpfr7gf32ordfi@4ax.com. ..

Quote:

>>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.

"Cor Ligthert[MVP]" <notmyfirstname@planet.nlschrieb

Quote:

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)

Quote:

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

Pardon?

Armin

dgk,

My message could be read wrong, what I mean is.

Why are you asking here questions while you have already in "advance" your
"own" incorrect answers and start discussing those as true?

Cor

"Cor Ligthert[MVP]" <notmyfirstname@planet.nlschreef in bericht
news:E979365B-7D26-461F-B97E-0FC032D1ABC0@microsoft.com...

Quote:

dgk,
>
What do you want to ask when you have already your (incorrect) answers.
>
Cor
>
"dgk" <dgk@somewhere.comschreef in bericht
news:qn8le3dj2alr17mrgjvmq1r22cmhavfa37@4ax.com...

Quote:

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

Quote:

>>>"dgk" <dgk@somewhere.comwrote in message
>>>news:k82le35h7tu7ap35tc23bpfr7gf32ordfi@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.

>

On Mon, 17 Sep 2007 01:46:39 +0200, "Cor Ligthert[MVP]"
<notmyfirstname@planet.nlwrote:

Quote:

>dgk,
>
>My message could be read wrong, what I mean is.
>
>Why are you asking here questions while you have already in "advance" your
>"own" incorrect answers and start discussing those as true?
>
>Cor
>
>"Cor Ligthert[MVP]" <notmyfirstname@planet.nlschreef in bericht
>news:E979365B-7D26-461F-B97E-0FC032D1ABC0@microsoft.com...

I'm not sure what you mean by discussing my own incorrect answers as
being true. I spent quite some time (a few hours) puzzling out why a
generic List (of X) wouldn't work as a datasource for a gridview. It
seemed to have built in rows and columns and it seemed to me that it
should work. I thought that perhaps I could save someone else from
wasting time.

Quote:

>dgk,
>>
>What do you want to ask when you have already your (incorrect) answers.
>>
>Cor
>>
>"dgk" <dgk@somewhere.comschreef in bericht
>news:qn8le3dj2alr17mrgjvmq1r22cmhavfa37@4ax.com.. .

Quote:

>>On Fri, 14 Sep 2007 08:55:28 -0500, "PvdG42" <pvdg@toadstool.edu>
>>wrote:
>>>
>>>>"dgk" <dgk@somewhere.comwrote in message
>>>>news:k82le35h7tu7ap35tc23bpfr7gf32ordfi@4ax.co m...
>>>>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.

>>