>>>>If it's a bad idea, go tell the Fox team that they screwed up :).
>>>
>>>In VFP I would do a check for a form property and if it didn't exist, create it on the fly. I did that mostly because I had to share code with other developers and merge it. In most cases eventually the check never failed and the property existed when code got merged. It wasn't a longterm solution.
>>>
>>>You can programmatically add controls to a form at runtime:
>>>
>>>http://support.microsoft.com/kb/319266
>>>
>>>Properties though I don't know about. I know you can create types at runtime and types can have properties, but I don't think you can add a property to a type at runtime. Maybe you could inherit from it and add a property or something. Still, wouldn't it require reflection since the property wasn't known at compile time? How else could you access it?
>>>
>>>This would be a good discussion in the net c# section where the net gurus would see it....
>>
>>I think Dragan was just being a contrarian ;-)
>>
>>Was thinking about this more in the car yesterday and still can't figure out why I would want to add a property to an object on the fly. Maybe that is something that is in VFP for tool builders, not tool users like me.
>
>Software is a tool, most of the time. Computers would be bricks without it; with it, they become useful. It enables the user to do something. The difference is in the user - is he another programmer or is he doing something else.
>
>Back to the subject, .addproperty() and AddProperty() (method and function) are actually a more of JavaScript-like way of building objects instead of rubberstamping them off a class.
>
>Again, as in the example I gave, I find it very useful in situations when I'm nor sure whether the object on which I'm operating has the property or not, and it's far less code to just slap it on and then read it when needed, regardless of what the object is. Even in such simple situations as
>
>loObjectRef.addproperty("lDidWeMeetAlready","Yes") && because now we did, i.e. this will be true next time I access the property
>
>This way I don't have to know whether the object has this property, and I also have near zero chance that I will be stepping over an existing property of the same name (if that's the case, I can create a sys(2015) name for the property), and this will work regardless of whether everyone forgot(*) to write code for that property.
>
>Specially handy for Scatter Name objects when you scatter from one table then want to insert into another, having a few fields more, or such objects simulated, when you start with createobject("empty"), then add properties at will and then use that to insert.
>
>Again, I don't want to be specific on any cases, uses and situations, and I don't want to answer any of "what do you need that for", because those inevitably lead to discussion over the specifics and individual cases, and the general issue remains unaddressed, like a blank envelope.
>

I am really having a hard time wrapping my mind around this. To me is a class is something that is thought out, designed carefully, implemented in code, tested -- all that good stuff. The idea of slapping a new property onto it at run time because I'm not sure whether the object already has this characteristic or not is something I don't get at all. Maybe I'm just not imaginative enough.