>In general I never use public variables - properties are far more flexible:
>
>(a) you can bind to properties but not variables
>(b) you can put validation in one place
>(c) you can add multi-threading support if required.
>(d) properties can be Abstract or Overrideable
>(e) you can restrict property visibility (e.g. with a private setter)

By public variables, you probably meant public properties. Yes, I see some advantages in using the Get/Set approach, such as we described recently in another thread, but whenever this is possible, I like to keep that clean with Public properties as, when comes time to migrate to another environment, this is usually a dropdown conversion instead of trying to migrate something which is too proprietary to the development environment.

>Even when you see no need for any of those initially you may need it later - and you can't just change that in the declaring module without recompiling all other modules that access that item - properties and public variables are not binary compatable....
>
>In C# we have implicit properties (IIRC the equivalent, automatic properties, was added to VB10) which makes using a basic property rather than a variable very simple. Also, in C#, the performance of implicit properties and public variables is the same (I assume the same applies to VB?)
>
>In short there are *no* good reasons to use a public variable.....
>Not just my 10c........ :-}

Thanks for the additional references