>Peter -- You mean you don't say that already? I have been doing so for years.

Nope. many times I'm the first one who explicitly calls the bug a bug, although this is sometimes not wise. Perception is important. Last year during two weeks we produced new builds for the test team on a daily basis, hoping it would help in meeting the deadline. Only later we discovered that people interpreted this high frequency as caused by test versions that were full of bugs.

>It is not possible to foresee all the effects of a design, no matter how carefully constructed, and there
>will always be effects that were not predicted. When my designs result in unfavorable and/or expected
>results, that is exactly what I say to a user.

But what you're telling those clients is not true. A good design has no unpredictable effects.

>BTW, in my little corner of the universe, a bug is defined as a VFP error which causes the application
>to abort; if the app runs without error but produces spurious results, we call it a design feature.)

Formally you may be right, but my definition is much broader. :)


>>Ah, 'one of the effects'... That's a good one. I must remember this one. Whenever a user comes to me with a complaint ("Arrgh, you see this bug?!") I can always tell them that it's not a bug but one of the effects of the design. :)
>>
>>>I have no recollection, other than it was a long time ago, here in the UT.
>>>
>>>Nor do I think that anybody ever said that it was by design, but rather that is was one of the effects of the design.
>>>
>>>
>>>
>>>>To be honest, I expected this reply. :)
>>>>
>>>>Can you recall who it was here on the UT that learned you and others that it is by design? Was it someone from MS or simply someone else?
>>>>
>>>>>You wrote: It cannot possibly be by design, as it has nowhere been documented.
>>>>>
>>>>>I disagree with your assertion. Simply because something is not documented does not mean it is not a result of the design. Some features
>>>>>are only "documented" by word of mouth, which is how Iearned of this, long ago, here in the UT.
>>>>>
>>>>>
>>>>>
>>>>>>Hi Doug,
>>>>>>
>>>>>>Your Nope is simply incorrect. It cannot possibly be by design, as it has nowhere been documented.
>>>>>>
>>>>>>The reason you mention is far sought, as it would have been only a simple extra piece of code to re-initialize the properties, without almost any impact on the performance.
>>>>>>
>>>>>>I am also almost sure that this flaw is not occurring in scx's.
>>>>>>
>>>>>>>Hi Peter.
>>>>>>>
>>>>>>>>'By-design' may be what has been told to you, but to me that sounds like a rationalisation, to hide the real reason: a design flaw or simply a blind spot for this when implementing it, in both cases a flaw they somehow didn't want to repair.
>>>>>>>
>>>>>>>Nope, Jim is right -- it's by design, and has been there since VFP 3.0. The reason is the way VFP handles classes: a class is a template for an object. As Jim notes, when you instantiate a class for the first time, the class is read into memory and any properties with "=" are evaluated. VFP then copies the class definition to create the object. Instantiating it again creates another copy, but with the same property values as the class. So, properties with "=" are evaluated for the first object only.
>>>>>>>
>>>>>>>(Thanks to Christof Wollenhaupt for explaining this to me.)
>>>>>>>
>>>>>>>Doug