Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
The m. variable thing
Message
De
22/11/2004 08:11:55
 
 
À
21/11/2004 13:45:50
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00962544
Message ID:
00963448
Vues:
7
Hi Walter,

>Can you explain me, why it is a VFP rule. I never did spot this in any MS documentation and never saw it explained as a rule.

This is one so fundamental what that I have difficulty to explain it ( with english ).
I try to us:
VFP language it is one grammatical, and every grammar has of the rules.
The parser rule in issue is this (narrow only to the variables and the fields context):
( applied in order )
- if a identifier name syntax is 'name', then it is a field or a variable,
- if a identifier name syntax is 'm.name', then it is one variable,
- if a identifier name syntax is '.name', then it is a field of the Alias.

This rule involves that the space of the names of the variable ones and the fields can be overlapped,
and, important what, that one of the fields it is over to that one of the variable ones.

Of course, because you uses two disjoined subspaces of names, the rule, even if applied, it generates turns out to you invariant. But the rule is applied however.

The problem it is this:
you focus the thought to the designtime,
but what you construct it must work to the runtime.
At runtime, without a prefix., VFP before scan the field list and after read the variables array.
If you want to read a variable, then this process have not sense.
The first the rule in order to reduce the problems is:
you only make what you want to make
( you remember the Ford phrase: what not there is not can break off!)
I rewrite with: the don't executed instructions cannot generate problems.

>VFP does not care whether you use m. or not.

And then? Tasks are important?
On _Access VFP put this.property ! ( this is sufficient for me in order to understand )

>Of course VFP itself has internal rules which determines whether to use a field or variable with the same name, but this in itself does not make it a rule.

Sorry, but this clause is not corrected.
A meta example:
when guides on the roads have a rule:
you must run on the track of right;
but if you run alone on a road,
then can say that not there is a rule,
and can run on the track of left.
But this is false, the rule remains,
you are to violate the rule because the conditions you allow.
It remains always the possibility that a day you must run in means to the others,
and the bad habit could make an ugly joke you.

>Not sure what you're saying here (as a dutchman trying to translate italian-english :) ), but I take this you strongly disagree with my standpoint. I have no problem with that. You're free to disagree, but my standpoint is where it is now and is not going to change in the near future.

You are free.

Fabio
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform