Drew Wutka
DWUTKA at Marlow.com
Sat Apr 16 16:36:37 CDT 2011
Finally, we agree on something. Glad you finally came to your wits... ;) <VBG> Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, April 15, 2011 5:38 PM To: Access Developers discussion and problem solving Subject: Re: [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. > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.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.