With the introduction of "Visual" Foxpro 3.0, VFP became a language
hosted by C++, completely dependent on the C++ classes. VFP allowed a
programmer to initiate a instants of a class, which created a name space
for all the class' properties and methods within memory. Initially the
namespace held the default values from the classes, which were inherited
by the object created in the code or from the Visual Designer. Through
the VFP program code or Visual Designer, the custom properties and
methods could be passed to the object's namespace to create a custom
object to be used by the application. This could be done either by
using the VFP Visual Designer or from code within the program.
This made VFP a kind of hybrid language made up of VFP language, VFP
database, and C++ classes and framework which could not be edited. This
also gave VFP all of the problems of a C++ application like running
within an event loop, responsibilities to do your own garbage
collection, (eg clean up all object referenced within the application
before closing it), and the dreaded C5 memory error, etc.
It made VFP applications much more difficult to debug and understand
with the very strict structure of the C++ classes to which the
application was liminted, and to try and understand some strange
behavior that appeared within an application from time to time, as to
whether a bug, a feature, or whatever.
Regards,
LelandJ
Ted Roche wrote:
> On 7/31/07, Paul McNett <p (AT) ulmcnett .DOT com> wrote:
>
>
>> Visual FoxPro, in retrospect, hindered my understanding of programming.
>> I'd put a <g> there but I'm actually quite serious.
>>
>
> Well, now you've got me worried, since I still consider VFP a native tongue.
>
> What aspects of VFP did you feel were bad to your understanding other
> languages? I've been power-cramming PHP, Python, bash, CSS and lots
> more into my head, and if there are habits I should un-learn that
> would help, I'd appreciate the insights.
>
>
©2007 Leland F. Jackson, CPA |
