jwcolby
jwcolby at colbyconsulting.com
Fri Apr 15 18:28:47 CDT 2011
>> A PROPERTY is the external name given to a variable which is encapsulated in the class. LOL, absolutely and unequivocally not true. It is the name of some data value associated with or encapsulated by the class but it is simply *not* always and necessarily a variable. Nor is it an invalid use of a property if it is not a wrapped variable! There are properties that do not even reference a variable at all and they are perfectly valid uses of property. I can take three booleans and return a true of all are true (and I do exactly that in one of my properties). It is a property (English definition) that the class is stopped when three child classes are all stopped. The child objects use threads and write to a status control on a form. I cannot (don't want to) close the form until they are all stopped - their threads are no longer running. The form asks the manager if it is stopped when I try to close the form. It does so by checking the boolean stopped property of the manager. The boolean stopped property (get) asks the child objects if they are stopped and returns a true if all three are true else returns a false. It is not wrapping a variable, you can't set the stop variable, there isn't one. It is a valid property however. I can take 16 booleans and "translate them" into an integer value from 0 to 16 if that is what I need to do. A property (English) is a data value, but it is not necessarily a stored value and in fact it is quite often a calculated value. The fact that you personally say that is bad practice doesn't impress me. If I use the property to calculate a state (data item) of the class that is a property (English) of the class the same as your stored value is. I understand perfectly well that a property is not a function (or method) but it has more properties (English) of a function than a variable - public or otherwise. I used "function with quotes at the start of the thread to clearly denote that a property was not a function. However a property (keyword) is a call. It pushes the current address pointer on the stack. A property set (or let) pushes the value on the stack. Inside of the property other lines of code can and do run. A property does not inherently have any storage. They can do anything that is logical for a property to do. When it returns it's value (if a get) is placed on the stack and it unwinds the stack. Sounds much more "function" than a dimensioned variable. Drew mentioned my "soap box". I do not have a soap box, I am simply insisting that we acknowledge the facts. I have no idea what goes on in VB6 because I do not use it. However I have used a class or two (or three maybe?) in Access so I do understand VBA. Obviously Drew is a better (and wittier) programmer than I but let's attempt to understand (and discuss so others can understand) what these things are, what they do and when we are using an English definition and when we are using a keyword, and when we are just using a vague kinda sorta definition. And when we are using an object. A property is also often an object in OO environments. John W. Colby www.ColbyConsulting.com On 4/15/2011 6:33 PM, Stuart McLachlan wrote: > Sorry, I can't agree with you there. > > A METHOD is a function. > > A PROPERTY is the external name given to a variable which is encapsulated in the class. > i.e. for all intents and purposes outside of the object, it IS the variable. > > "PROPERTY SET" and "PROPERTY GET" are methods. > > The fact that you can also perform other actions when you SET a variable is irrelevant. You > should be doing what it is saying and setting the value of the variable. When you GET it, you > should be retrieving the value of the variable. > > Wiile it is possible to create SET/GET functions for a property so that GET doesn't return > what is SET, it is a gross abuse of the whole Object concept.