I think the "vfp does this...." attitude had a real effect on causing corporations to drop VFP too. As you said if 85% of the programmers out there always think a certain way, and you want to think opposite, there's not too much chance, the other guys will let you play in their sandbox.



>Walter
>
>In case it is lost on you, I developed using Foxpro/VFP since circa 1989/1995 respectively. So, I am aware of the arguments from both sides of the fence. I just think that for Perrti to glibly make reference to the AddProperty function and compare it to the lines of code that Andrus produced for Alex needed squaring off somewhat.
>
>It seems that a lot of Fox devs seem to be placing high hopes on the "ethnologica" offering to keep themselves relevant going forward - I sincerely hope that they are backing the right horse and that the company in question realize a commercial advantage for their efforts in trying to do what MS was not prepared to do. The Fox community tend to like things "for free" and as much of the Fox third party market realized over the years, if it isn't cheap, it won't sell. Time will tell.
>
>I guess I made all the same arguments that you and others make for VFP's superiority and I argued with you and for you against the likes of JVP and the PA crew. However, after using .NET in many commercial environments, I can tell you that there is no occasion that I have ever wished I had VFP to handle the job. I have seen your arguments about how you can only do your data-intensive stuff using VFP and if that is your experience, then good for you. However, a number of applications that I have been involved with have been to replace VFP applications in enterprise-scale environments. The Fox developers sniggered and sneered that we would fail for many of the data oriented reasons you have cited. However, they were wrong and the systems succeeded over and above expectations. Those companies no longer employ VFP developers ... 'nuff said.
>
>-=Gary
>
>
>>Gary,
>>
>>>I have seen a few threads on this board where VFP developers delving into .NET ask this or a similar variant of this question. I can tell you that it's only VFP developers who ask this question. The rest of the IT world seems to have managed without adding properties at runtime. Go figure :)
>>
>>I've seen this argument a little too often. Though you might be right in your assesment that you've only seen this from VFP developpers, but truly that does not mean the request is not valid...
>>
>>Now, I actually agree that in this particular case you're right that you seldomly want to add a property at runtime. I've only used this in very exceptional cases (Adding a property to _Screen or other fixed objects for example)
>>
>>That being said, if you think that the rest of the IT world don't ask for it because of its bad practise, I think you'll have to think again. For example, a VFP developer might ask how to do SQL on local ADO.NET data. Up until LINQ everyone except the VFP developer would have answered that data processing belongs to the server. With LINQ this has changed toward the VFP attitude.
>>
>>IOW, it is not that things are not supposed to be handled this way, but just because the other regular tools don't offer you these options. IOW, you don't know what you dont know. The same thing about using dynamic languages like VFP as oposed to strict type languages: The same arguments come up again like compile time type checking.
>>
>>Great if you compare VFP with .NET, but actually when using this argument you really don't understand what the difference is between dynamic and strict typed languanges:
>>
>>1. Dynamic languages can have (optional) compile time type checking, as proven by ethnologica. It is just that you're not forced to go through hoops of reflection. You'll have best of both worlds.
>>
>>2. I don't know why people think that compile-time checking is so great. It actually is and was utterly cumbersome. I know that my C/C++ teacher at university once said that he had to send his code to a central C compiler, wait for about half an hour to find he had made a typing or casting mistake. Oh great... Why on earth, with all the processing power available today, we still don't have type checking when writing the actual code ???
>>
>>Food for thought, in stead of slamming the other in silly language wars.