[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

On 4/15/2011 11:05 AM, Drew Wutka wrote:
> LOL.... what a long winded way of saying 'No, it's not documented, it's
> my personal definition'.
>
> Your view here is based on a granular perspective of VB6 (remember, we
> are talking about VBA and VB6 here, there is a CLEAR defined difference
> between a Field and a Property in .Net).  You are looking at the
> definition of a property from INSIDE the class.  If you take a more
> bird's eye view of class a property is a value.  A class is an object.
> Regardless of what each individual line of code within a class module
> says, a class is an object defined and structured to represent
> something.  A Function is set of instructions that you start with a
> call.  A Class is an object, that you create, mold, store, manipulate,
> etc.
>
> With this type of view, it is irrelevant as to whether a property is
> defined with a Public statement or a property statement, it is still a
> 'property' of a class.  If you were to build a 'Rubber Ball' class, and
> gave it a Color property, from the outside world (to the class), the
> property is a value that can be set or retrieved (or one or the other).
> The outside world, to the class, doesn't care how it is defined.
>
> .Net makes a distinction, in documentation and intellisense.  But
> Property is a keyword and Field is not.
>
> But back to VBA and VB6, let's go even more granular then your view
> here.
>
> What is the machine code difference between:
>
> Public MyValue as string
>
> And
>
> Property Get MyValue() as String
> MyValue=strValue
> End Property
> Property Let MyValue(strEnter as String)
> strValue=strEnter
> End Property
>
> ???  Do you think that thep code, when this is compiled, is doing
> anything different?
>
> Drew
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Friday, April 15, 2011 7:44 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] First real stumble with using VB.Net over VB
>
> Drew,
>
> I can't show you documentation but what I can do is show you that a
> property is a function of sorts.
>    It has an entry point on the stack, it accepts a parameter, it returns
> a value.  It has a keyword
> in the VB language.  It can run any amount of code inside of the
> "function", and do anything that is
> legal for a function to do including dimensioning, reading and writing
> other variables, running
> loops, doing if then / select case etc., reading and writing to the
> disk, downloading files from the
> internet, formatting your hard disk... you name it.
>
> A property is a function.  It happens to be targeted to wrapping
> variables and exposing them to the
> outside world but that is not all it can do.  A property does not
> *define* the variable, that is
> done in the dimension statement.  A property does not "own" the variable
> that it wraps, it is simply
> *returning* the variable.  A property does not have any data storage
> area on the heap unless it
> happens to dimension its own variables inside of the property, and even
> then (except for strings and
> statics) most variables inside of functions are stored on the stack.
>
> A variable, whether global or private is nothing more than a reserved
> area of memory on the heap
> sized to accept a specific data type.
>
> A variable is not a property, as you can now plainly see from the
> explanation above of what a
> property is and what a variable is.  How can you possibly expect them to
> be or work the same.  They
> are different things entirely.  The fact that the IDE displays the same
> icon is unfortunate (for
> you) because it causes you to have false expectations.
>
> Stop arguing about it and accept the reality.  I didn't make the
> language, I just look at what
> things are and use them appropriately.
>
> 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.
>
>