>>IMO, mdot is largely a matter of VFP folklore. Wake me up when it gets to Fox vs Clipper, or even better, Spectrum vs Commodore.

I was a TRS-80 man myself...

Re mdot: this argument boils down to 2 historic decisions:

1) Allow reference to fields without alias prefix, and
2) Introduce objects that can exist alongside effectively identical aliases.

Had the originators insisted on alias prefixes, there could have been 26 aliases and no need for m.

Until of course objects were allowed that could look identical to coexisting aliases. The expectation was that people would know better than to create objects with same name as alias, but still there's extra overhead needed to make sure, unless you use mdot.

More recent IDEs avoid all this by only having objects rather than aliases and requiring the object prefix. But to add to the fun, some of them instead allow an implicit "this" for methods or properties, similar to VFP's implicit selected alias. Then they add method overloading with intended code identified by number of parameters. The combination is so joyful that I once paid $ for an obfuscator that condenses most code into the same named method across the whole app. No doubt there are developers unconsciously mimicking this tactic for the enjoyment of future developers trying to maintain the code.

Having spanned much of the competing era as various fireflies outshone brightly before disappearing, there's all sorts of calculators, puzzles and conventions embedded in VFP that are mostly forgotten today until they bite and probably would be handled differently if starting afresh. I just reflect that perfect is the enemy of good and press on.