Compiler arbitrarily breaks large existing code base AGAIN i

Posted by Simon L. Prinsloo on 11-Nov-2015 02:54

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



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?

All Replies

Posted by PatrickOReilly on 11-Nov-2015 05:22

I feel your pain Simon.

How about this for a solution: PSC adds a compile option called "strict names", or "no abbreviations", or something like that. This concept exists in some other language compilers. When compiling with this option the compiler will not accept abbreviates names in any namespace. All names must be strictly matched. Namespace precedence can remain as it is - as Simon noted - but this approach would at least make the results unambiguous.

The first time we use this we may find some code that needs fixing (our standards disallow abbreviations, so we SHOULD not have an issue - but programmers are sometimes naughty!). Thereafter life will be better IMO.

For those who like short-cuts in the code, well you may continue as you are.

Posted by Stefan Marquardt on 11-Nov-2015 06:11

12 points, I am asking/proposing that meanwhile ~10 years!

I think I heard/read it on a slice in Copenhagen but perhaps I was dreaming a while :-)

Posted by Patrick Tingen on 11-Nov-2015 07:22

No, you were not dreaming, it was asked for in the 'Language & Tools info exchange' session. There were more requests along this line, but it essentially boiled down to a -strict startup option.

I could not find an enhancement request for it, so I created it. Vote for it here: click

Posted by Evan Bleicher on 11-Nov-2015 07:33

As noted, customers have raised this concern in the past and Simon’s post summarizes the challenges with introducing object oriented constructs into a language which supports a long standing flexible name matching facility.

OpenEdge development is in the early stages of planning the 11.7.0 release.  The specific features and capabilities which will be in that release have not been finalized.  However, the Core team has been discussing the challenges you raised and we are in the preliminary phase of designing an enhancement to the compiler infrastructure which will allow the ABL developer to select options which will customize the compilation process.  Two candidate options are the ability to disable field abbreviations and the ability to disable implicit field references.

During the 11.6.0 development process the Core team posted to the 11.6.0 ESAP community (early software access program) a number of our functional specification and then followed that up with access to the implemented functionality.  This allowed customers to provide their input on our proposals throughout the development process as well as allowing us the opportunity to incorporate feedback when possible.  It is my intention to follow this same approach with 11.7.0 and the functional specification for the compiler options feature would be a candidate for including in an early 11.7.0 ESAP.  I would like to encourage you to participate in the 11.7.0 ESAP (when that becomes available).

Posted by James Palmer on 11-Nov-2015 08:12

I have to say, this more open approach to release content design is a massive step forward indeed. It was a real pleasure hearing Brian Bowman talk about the Database features brought in as a result of consultation, and hence a pleasure to contribute ideas to 11.7, and future updates.

Long may it continue. This is one of the keys to rekindling interest in Progress!

Posted by Paul Mowat on 11-Nov-2015 08:19

I have to agree with James. It's great being able to contribute to the future of OpenEdge and actually have a input into what will go into the future releases.

This thread is closed