Hi Peter,

I feel that you are RIGHT ON as regards this serious problem and the extreme deficiency in the Help! It took me a while to even find the passage that mentions "M. and M->" with it's simple statement that field names take precedence. Aside... I was unsuccessful in locating any notation about it in Hacker's Guide (VFP7).

My judgement, though, is that it is/was not a "bad design decision" but rather that it is just severely under-documented. There needs to be warnings sprinkled liberally throughout the Help in my humble opinion.

I do agree that taking steps to reduce its possible occurrence is very sensible. On the surface your proposals seem to make good sense, though I suppose the devil is in the details (for instance, how would 'HIDE TABLES...' or the 'LPARAMETERS...' be designed to function, in detail?).

I have another proposal to add to the list. I have tried to cover it off in another wish #1094 but it has garnered 3 votes with the average of 1.67. I think there's one or two people out there who feel obligated to rate all of my wishes at 1 < s >.
In any case I'm sure that wish does NOT cover all the bases, but here's the idea - allow us to code so that only tables/cursors explicitly SELECTed are indeed selected - none become selected by default. A good remedy for the potential Mdot problem is to never have a table selected, so if we could assure that state throughout our code then it wouldn't be the problem it is today.

All proposed remedies involve code changes, which I do think is inevitable for this problem.

Should be an interesting discussion.

cheers


>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.