rivate scope identifier, and you should make a difference between local, private parameters as well as calling by value or by reference. That might help you in case of ldate_ok, which might be a local date of the "ok" or a logical field describing wether a date was ok...
No, I don't do it myself, I just realize the possibility. And yes, in inherited code I argue for adding the MDot (en passant!): it is just a question of time until the first error crops up. After that the budget is usually no problem <g>.
>2 The decision to use the dot not only for table referencing, but also for variable referencing and object referencing, has worsened things.
You could have stayed with the -> syntax, which was a PITA (at least for my fingers <g>). Rigorous mDotting eliminates any ambigous statements.
>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?!
Since the dot is possible in object and table syntax, following your argumentation the memvar should be "inspected" first. In this situation, how could you write any routine (using the table-dot) accessing a table field without the danger that a combination of object with the same name as the table and propertyname like the field name might corrupt it without your notice ? The case of having a error from a different field type or non-existing property would be better than the danger of "silently acessing" the object instead of the table. And NOW forcing back the notation for tables to "->" ?
...
>Such improvements should help tackle real-life problems that are caused by former unfortunate design decisions.
I'ld rather have more help in refactoring: special compile switches which at runtime trace accesses to memvars without m., something like VB's "option explicit" to enforce/check datatyping, perhaps even a protocol for "misnamed vars" if run under coverage profiler. Helping you remedy the previous mistake, not building other structures, which might give the opportunity of new mistakes. And yes, it bites me sometimes as well.
>I'd like to create one or more wishlist items, but first I seek debate here.
my 0.02 EUR
thomas
