[AccessD] First real stumble with using VB.Net over VB

Actually John, now that you've come down a bit on your soapbox, I will
try to clarify for you.

As a VB/VBA programmer, nothing I ever read about VB referred to 'Public
SomeValue as string' as a FIELD. In fact, it was always referred to it
as a PROPERTY of a class object.

I have ASKED if you have any supporting documentation, like some
Microsoft white paper, or something I should have read when becoming
proficient in VB(6/VBA), where I would have learned that the correct
term for 'Public SomeValue As SomeType' in a VB/VBA class module was
FIELD.

I can show you PLENTY of documentation where the reverse is the case. 

http://msdn.microsoft.com/en-us/library/aa262343(v=vs.60).aspx 'Visual
Basic Concepts / Customizing Form Classes'

Straight out of the MSDN, when talking about Class modules in VB6.  It
refers to PROPERTIES, METHODS AND EVENTS.  It DIRECTLY refers to 'Public
Comment As String' as 'click on it to play back its Comment PROPERTY'.

Or how about:

http://msdn.microsoft.com/en-us/library/aa240810(v=VS.60).aspx 'Visual
Basic Concepts / Class Module Step by Step'.  You won't find the WORD
'field' on that page, and it refers to 'Public Name As String' AS A
PROPERTY.  Straight from the designers of VB 6's mouth, JWC.

Now admittedly, I'm only bringing MSDN articles into the fray.  I'm not
taking your approach, that you've been programming since you built THE
FIRST Antikythera mechanism, so what you say is how it is.

To begin with, you are absolutely, 100% incorrect in stating that there
is ANY difference in performance OR FUNCTIONALITY between:

Public MyValue as String

And

Dim strMyValue as string
Property Get MyValue() As String
MyValue=strMyValue
End Property
Property Let MyValue(strEnter As String)
strMyValue=strEnter
End Property

The only difference above is that one uses 1 line of code, the other
uses 7 lines of code, in the source code.  That is it.  When you express
what else you can do with Get/Let statements, you are going OUTSIDE the
scope of declaring what a BASIC property is. Yes, you can put error
handling into the statements above, but that changes the strictest
definition of a 'SIMPLE' property.  You can add extra arguments, logic,
processes, etc.  All going OUTSIDE of the definition of a 'simple
property'.  And in VB 6, there is ABSOLUTELY no problem with taking a 1
liner property, and converting it until actual Get and Let statements
(or Set) for more functionality down the road.  In .Net, there IS a
problem, because if you are using Reflection, the Field is now a
Property (in .Net terms), so it will be in a different collection in
Reflection.

Back to my original point, to this thread, I have been using .Net for
about a year now, since I was out of the development world for a while.
I have only recently had a reason to use Reflection, which I stumbled
on, because as a VB 6 Programmer, there WAS no distinction between
property declaration types like there is in .Net.  I am not complaining
that there is a difference, in fact, it is quite handy to have two
separate Reflection collections to use.  I was simply stating that it
was a DIFFERENCE between VB6 and VB.Net, for those that haven't yet, or
are just crossing the bridge into the .Net world.  Like saying that
there is no more Variant variable type.  Would you like to give us a
tirade about how Variant types never truly existed, and how I personally
will never understand that concept?

Seriously John, you need to read more than a few lines of my posts.  A
lot of what you have said makes you sound like an a$$, not as a skilled
professional.  My post had nothing to do with who is a better programmer
<witty sarcasm>, because there's no question I am the better
one...</witty sarcasm>. ;)

Drew
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, April 15, 2011 3:19 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] First real stumble with using VB.Net over VB

Drew,

What is clear is that you are using the definition of a property as "a
unit of information about" 
which absolutely one of many English language (and programming)
definitions of property.

You have already told us (as have I) that a public field and a property
(keyword / function) behave 
differently.

The problem is yours not mine.  I understand and use your definition in
the same way you do.  I do 
not expect a public field to behave in the same way that a property
(keyword / function) does 
because they are fundamentally different things.  Personally I do not
call a public field a 
property, I call it a public field (in programmer speak), though of
course it is a property in 
English language speak.

You no longer expect them to behave the same because you have discovered
that they are fundamentally 
different things.

Where is the argument?

Everyone now understands that you want to (and will probably) call
public fields properties and 
moan that they behave differently.  To which I respond - NSS.

John W. Colby
www.ColbyConsulting.com
The information contained in this transmission is intended only for the person or entity 
to which it is addressed and may contain II-VI Proprietary and/or II-VI Business 
Sensitive material. If you are not the intended recipient, please contact the sender 
immediately and destroy the material in its entirety, whether electronic or hard copy. 
You are notified that any review, retransmission, copying, disclosure, dissemination, 
or other use of, or taking of any action in reliance upon this information by persons 
or entities other than the intended recipient is prohibited.