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

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

Well of course you are.  And wittier as well.

John W. Colby
www.ColbyConsulting.com

On 4/15/2011 5:09 PM, Drew Wutka wrote:
> 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.
>
>