Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
The m. variable thing, the sequel
Message
De
29/12/2004 04:24:56
Walter Meester
HoogkarspelPays-Bas
 
 
À
29/12/2004 02:26:41
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Database:
Visual FoxPro
Divers
Thread ID:
00969478
Message ID:
00972843
Vues:
67
Hi Mike,

As Fabio said, using m. strategy in itself does not prevent you from the problem, if in one instance you forget the m. and now inmediately confuses fieldnames for variables. This problem is more likely to occur when:

1. You don't use m. consistently (but use what is suggested at the wiki)
2. You don't use naming conventions to avoid collisions between fieldnames and variables.

>No one is pushing anything down your throat. The fact is only dbase-like languages have this issue. How you deal with it is your affair. I know several really good VFP developers and they're using mdot. IMO technical reason must outweigh personal preference.

I know several good VFP developers who do not use m. FWIW, I do regard myself as a resonable VFP developper and do not have any problems without using m. so, your point is ??

>To use analogy, most programming languages are like pants with buttons in the front. VFP is like pants with a zipper. There is a chance that something might get caught in the zipper. I think wearing underwear will reduce that risk. You can certainly arrange things so nothing gets caught in the zipper. Also, in the case where the temperature gets down to -30C, you will be less ... protected. You'll still have risk. You won't be able to zip up quickly and without care. You don't want to wear underwear because they make pantylines on your ahem ... backend - you don't like how they look.

I do miss the use of naming conventions to avoid collisions here to avoid problems in your analogy. Again you're fighting an academical battle that might have reason in strict theory. However in practise this is a non issue in my experience. And even then the theory is not complete either. You'll have to use strategies to avoid collisions with VFP keywords like THISFORM and THIS and with object valiables, like Fabio is proposing. To apply m. for security reasons and leave a gap open often is more worse than no security att all.

Again, my personal preference not using m. is outweighing the strict theorectical chance that somewhere In the future I'm going to be bitten by confusion of fieldnames and variables and I've got to fix that problem when needed. I'm certainly not willing to decrease the (my) readability of sourcecode that has a far worse potential source of bugs than the problem you are describing.

IMO, this is one topic that continues to be a fight between camps and does not have any significance in VFP development in general. IOW it is just a waste of time one camp trying to convince another: Not very productive.

Walter,
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform