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]

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]

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.

 

[Guest]

Here is a quote from "Programming Misrosoft Visual Basic .Net" by F. Balena.

Visual Basic .Net documentation and tools - such as Intermediate Language
Disassembler (ILDASM)....make a distinction between class properties
implemented as Public variables (known as fields) and properties implemented
as Property procedures (the real properties). While most of the time you can
ignore the difference and use fields as if they were first-class properties
(as you do in previous Visual Basic versions), sometimes their different
implementation explains subtle differences in their behavior.

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

 

[dgk]

Here is a quote from "Programming Misrosoft Visual Basic .Net" by F. Balena.

Visual Basic .Net documentation and tools - such as Intermediate Language
Disassembler (ILDASM)....make a distinction between class properties
implemented as Public variables (known as fields) and properties implemented
as Property procedures (the real properties). While most of the time you can
ignore the difference and use fields as if they were first-class properties
(as you do in previous Visual Basic versions), sometimes their different
implementation explains subtle differences in their behavior.

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

Yes, I guess that is the case. I would have thought that databind
would accept any repeating structure (I guess anything with
iEnumerable?) but clearly not. Ok, I learned something new today.

 

[dgk]

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]

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.

 

[Guest]

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

 

[dgk]

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.

 

[Hal Rosser]

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?

One advantage to using public properties vs public variables is that you can
exert some control and do some data validation in the property set method.
For instance if one of your variables is "age", you might want to avoid
assigning a negative value to it.
If you use public variables, it may be best to not put your name in the
documentation.

 

[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

 

[Cor Ligthert[MVP]]

dgk,

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

Cor

 

[Armin Zingler]

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

 

[Herfried K. Wagner [MVP]]

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:

In addition to the other replies:

Note that chaning a public field to a public property after the class has
been shipped may break existing code if reflection is used to access the
field/property there.

 

[Cor Ligthert[MVP]]

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

 

[dgk]

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]" <[email protected]> schreef in bericht
news:[email protected]...

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.

 

[dgk]

One advantage to using public properties vs public variables is that you can
exert some control and do some data validation in the property set method.
For instance if one of your variables is "age", you might want to avoid
assigning a negative value to it.
If you use public variables, it may be best to not put your name in the
documentation.

I always wonder they they allow stuff in a language and then tell you
not to use it. I've always used public variables over properties
whenever it doesn't make sense to filter the input or format the
output. I think that it's cleaner to look at and quicker to write.

The object in question is used to hold data from a few datasources and
show it. I'm not validating what is already in the database, that
would be wasted effort. It seemed like a public variable would be fine
in this scenario. It would have been better if it would actually
databind, of course.