My opinion can go two ways whenever I'm confronted with the fact that a feature/oddity is "by design". In certain cases I accept the design decision, in other cases the feeling prevails that "the design somehow stinks" and that we should tell this to the foxteam.

An example of what I regard to be a stinking design is the MDot handling. There's a full text on this subject: http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~VFP

Yesterday I was forced to read it all once more and now accept the full consequences. Why? An error condition ("Operator/operand type mismatch" or something like that) occurred in one of my library routines, after years of robust functioning. The routine did not use MDot (m.) and in this special case there was a variable name that was also the name of a field in some irrelevant, but currently selected, table.

What are the full consequences? That I'll have to review (at least) my whole library! I'll have to go through all code and apply the advised rules, which are not simple and straightforward. And then I'll have to test, test, test.

Why do I think it stinks?
1 The official help texts amply mention the MDot problem. Essentially, there's no official text about the problem. Oh yes, I know there's one place where they talk about it, but there's no place where they tell you to always use the mdot in at least library routines. They leave the decision up to you. And that's a terrible 'advise', for all developers who decide not to use the mdot, introduce a condition comparable to the y2k problem, but now with an uncertain date of misbehavior.

2 The decision to use the dot not only for table referencing, but also for variable referencing and object referencing, has worsened things.

3 The decision to first look up in the table, and only then look up in the list of variables, is killing for routines that were developed with no such table in the developer's imagination at the time of developing. Imagine a developer constructing a routine that e.g. checks for the existence of an app; why on earth must this developer be aware of the possibility that a table could ruin the code?!

We have seen a lot of improvements of the language over the years. One of the finest improvements was the introduction of local variables, which really helped in making code more robust. I think that additional, similar, improvements must be introduced by the foxteam. Here are some suggestions that can help in building more robust code:
- SET {keyword} TO {value} LOCAL && See Wish #530
- USE (table) LOCAL | PRIVATE | PUBLIC
- HIDE TABLES ALL | EXCEPT (skeleton) | EXCEPT (list) && always only local
- LPARAMETERS( TABLE LocalAlias, VARIABLE LocalVar )

In essence, these suggestions are based on the idea that not only variables and properties must be scopeable, but that settings and tables should be scopeable too. The degree of scoping that is possible with SET DATASESSION is currently too limited.

Such improvements should help tackle real-life problems that are caused by former unfortunate design decisions.

I'd like to create one or more wishlist items, but first I seek debate here.