Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Foxpro Life
Message
From
09/04/2017 19:24:53
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
09/04/2017 15:01:49
General information
Forum:
Visual FoxPro
Category:
Contracts, agreements and general business
Title:
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Network:
Novell 6.x
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01649781
Message ID:
01649988
Views:
77
>Chen--
>
>There has been a long running debate by VFP developers on the use of m.dot for variable notation vs. using just the variable name; i.e. using a variable name as "Variable" rather than as "m.Variable". When a named variable such as "Variable" is first encountered by VFP, it has to determine if it is a table field or an actual variable. If a table name is found with a field name the same as the variable name, then the value is assumed to be the field value. However, if the variable is prefixed with a m.dot (m.Variable) then VFP processes it only as a variable. Additionally, if fields are referenced only by their names (without the alias name) then the same collision could occur if two tables have fields that have the same name and neither table is the current selected table -- in this case the first table would be selected which might not be the correct table. In my opinion table fields should always be referenced with their alias; i.e. tablealias.fieldname. And, then variables are referenced by their names. The two are never mixed.
>
>I always found the VFP compiler behavior to be a very sloppy practice (in general I find that xBase is a 'sloppy' language which is my opinion). I much prefer not to use the m.dot as I see it 'cluttering the code' and not providing any real value (other than to the compiler because of its sloppy behavior). In my opinion, programmers are developing code to make their user's jobs easier. In the case of VFP compiler, it should make the developers job easier (i.e., not require cluttered code).
>
>So would it be possible to enforce the following in the Advanced VFP Compiler (Can this be controlled via a compiler directive or switch?):
>
>1. Variables must always be declared as LOCAL with a type or as passed parameters with type. I would not want PRIVATE or GLOBAL permitted.
>
>2. Can variable types be enforced? The default value assigned is based on variable type; i.e., Integer/numeric values would default to 0 or 0.00, Boolean to False, Character/String to "" (empty), date to the current DATE value, and any object variable to NULL. Now in doing this there should be a type that is a variant which is determined at run-time...
>
>3. Can field names only be referenced by the alias as in tablealias.fieldname? If a field is referenced without the alias, it is a variable and if not declared in a LOCAL statement then it is a compiler error.
>
>4. The use of m.dot is permitted for backward compatiblity but not required. Variable names must be declared as LOCAL

Re m.dot, what John said.

Re 1, 2 and 3, please don't. We've discussed this to death and the decision (as I remember it, but we're getting old...) was that we got tons of code which runs as-is, and changing something so fundamental is going to break a lot of it (even as an option - someone downloads your code and compiles it with wrong settings, booom) and still won't make Fox the world's most popular language.

Re 3, I have a distinct example where I NEED private variables. Passing a SQL string containing ?puParam pieces to an object in charge of executing the SqlExec (with all the error handling, handle checking, reconnecting if needed, etc etc). If puParam is not defined and initialized as private, the handler's methods won't see it, bang.

Mind you, Chen asked for bugs to be reported, not a wish list.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Reply
Map
View

Click here to load this message in the networking platform