>>If you have different prg's with subfunctions/procs in you app - NOT all sub-procs made visible via set procedure, those sub-prcedures meant only to be used for the calling program on the basis of the defined search path (module functions if you like) at least vfp6 sometimes used the wrong procedure, while FP picked the correct on. Verified when porting a large FPW app where a kind of template-pattenr was used in each module and I had up to 48 functions with the same name. Terrible by today's standards, but in FP an attempt to sturcture method naming via one of today's most simple patterns. Had not check on this particular insect lately...
>
>This sounds like something that didn't hold in later versions but you couldn't know at the time. It was really hard to predict what will stay and what will change.

It was not a brilliant idea, but it had some good points: it allowed for controls to be copied with the "event methods" already filled, but only as a call to a prg-function and a reliable blueprint. And since "methods" were not available it implemented automatically a "module" concept.
>
>I remember that in mFoxPlus we imitated Fox's usage of underscore to prefix the system variables, i.e. those in use by our framework, to distinguish them from those local to the application. And of course we bet wrong... FP2.0 came and sure enough our _text variable now became a system variable, and even worse, it had to be a number.
>
>One thing I've learned, if you're about to invent variables that may sound like candidate system variables, don't do that in English... hence _sistem, _tekst, _brlin (not _lineno).

And let's hope that script languages translated into the host languages remain a thing of the past...