Compiler arbitrarily breaks large existing code base AGAIN i

It is still early, yet my day has been ruined again by the compiler breaking my code....

While my whole workspace was error free when I left, a lot of stuff not longer compiles.

The reason? References to static members of a particular, frequently used, class are all of a sudden invalid, even though code completion shows them as valid.

So what changed? A new field on a table happens to have a name of which the first two syllables matches the name of the class, and since the compiler gives preference to abbreviated field names above exactly matching class names, it now try to apply the class member references to a field.

We have two options:

1. Rename the field to something less meaningful.

2. Go through all code and fully qualify the class name everywhere. This has the added bonus that we have to keep writing it out in the future for this class, as our preference is that code completion should insert a USING, rather than inserting a fully qualified class reference.

PCS's position on this

I logged the current behaviour as a defect in the past, but PSC declared that the code is working as it was designed and advised me to log an enhancement request instead. The design intends to prevent pre-existing code from breaking once OO is introduced.

I can think of two ways to achieve that objective, but either one will potentially break some exsiting code. But in this case PSC chose the implementation that worked each time in the past when a new name space was introduced to the compiler. So while they were consequent, they did pick the more harmful implementation option. That choice leads met to feel that resolving this is not an "enhancement", it is fixing a defect that sprouts from the design already.

There may even be a perfect solution, but I cannot think of one.

So what are the options:

Option 1: The current implementation

To maintain compatibility with older code, name resolution of new types of objects are always added to the end of the parser. Hence field names, which were there since the beginning, resolves first and OO constructs, which were introduced last to the language, are resolved last.

Note that even for the first namespace in the hierarchy this is not fool proof. Exact matches on field and variable names will take precedence over abbreviations. So by introducing a variable name matching an abbreviation in the code will break that program and introducing a field name matching an abbreviation may wreck havoc all over the code base. What is more, the code may actually compile, but bind to the wrong field/variable and cause runtime errors that may be difficult to track. But that is the price we pay for lazy code and we all accepted that since the first release version of the Progress 4GL.

But the namespace is evaluated completely and only if there is no object matching the name at least partially, the parser moves on to the next namespace.

The current implementation just wrecked havoc all over my existing code base. I will have to fix multiple programs and ship it again, or forever live with a field name that breaks our standards, hence must be looked up every time we need it.

In the past it caused me to change my build process to a two step procedure in order to compile a third party package separately, as it had class names clashing with three field names in the database. We also had to make our own copy of the offending class with a different name in order to use it in our own code. I can't remember the detail, but simply inheriting from the original class did not work either and caused errors as well.

Option 2: Search all namespaces for exact matches. If that fails, repeat for abbreviations

The idea is to do the strict matching through all the compiler's namespaces first and repeat the process for abbreviations if the first part failed in all namespaces. (As an enhancement, I would prefer the second pass not to happen at all, unless I specifically ask for it with a compiler option or start up parameter).

So what would happen if all namespaces are scanned for exact matches first and, only if that fails, the relevant ones are scanned again for abbreviations?

1. Properly written, existing codes base would be unaffected by the schema change. The exception would be when the field name is also an exact match to the object name, but that is an order of precedence issue that will exist in any solution.
2. If an field name abbreviation is used in code, that program will continue to compile as long as nobody goes back to it and insert an unqualified reference to the class. If this happens, the programmer has the source open in any case and can either do the good thing and fix the abbreviation(s) or take the lesser plan of prefixing the object with its namespace (presuming it has one).

Conclusion

In my view, the current implementation may be as per the design, so the code may not have a defect, yet I consider the design itself as defective and would very much want this to be handled as a serious defect, rather than a nice to have on the enhancement request list.

Am I missing something?