A new feature was introduced with 11.7.0 called COMPILER OPTIONS. This feature allows a developer to set rules for the compiler to enforce stricter compilations. The feature is documented under the COMPILE statement [ OPTIONS | OPTIONS-FILE ] phrases : documentation .
This new feature grew out of an outreach program with the Progress Communities : Strict mode for the ABL Compiler - Community input is requested
There has been continued discussions under Communities through the ESAPs leading up to the release. One particular point discussed was how the compiler reacts when the enabled rules for COMPILER OPTIONS are broken within the compiled source. The initial implementation was to generate an error at the first failure and stop the compilation. This was deemed too difficult to manage by the developer. So, we updated the implementation to generate error messages with each instance of failure but continued the compilation to the end, but do not generate r-code. This is currently how it is implemented in the 11.7.0 FCS.
However, there was continued discussion between the final ESAP and the release that not generating r-code makes the feature unusable in certain cases. That brings us to this posting.
We are now considering a change for an 11.7 service pack and 12.0 to the feature. We would change the errors generated when the rules for the OPTIONS are broken to warnings and if the only issues seen during the compilation were from the options then we would generate r-code. That is, failing to meet the standards of the COMPILER OPTIONS would result in only warning messages that would not cause the compilation to fail.
Again, we would like to hear what the community thinks of this.
Okay, so the discussion has simmered.
The real answer is that Community wants both. Or, more to the point, control over it.
Instead of rushing a change into an early 11.7 service pack I am going to take a look at implementing something along the lines of the sub-option described here in 12.0. We will leave 11.7 alone for now and see what we can put together for 12.0. Then we can consider porting something to 11.7 in a service pack. I am making no promises here! We may leave 11.7 alone, we may downgrade to warnings, or we my port the 12.0 changes (if they happen).
I will try and get a pseudo-specification for 12.0 posted here this weekend.
I'd prefer if the behavior was controlled by a :ERROR or :WARNING switch on the option the same way debugging levels are set in the various LOG-MANAGER settings.
That way the developer can control the feature's behavior to match their current requirements and there's no second-guessing required.
No options no nothing. It should be treated as an error, period. If you ever abbreviated database fields and keywords, you should get slapped in the face. Also period. And yes, I will actually slap every idiot that ever abbreviated database field and/or a keyword, accidentally or intentionally, I don't care. Just deal with it. + ABL should be case sensitive. Period. This is a very long overdue option. Thank you for that.
I do love the passion and verve shown by tpavlovic... (yep poorly written code has kept many of us awake at night).
Having said that... the answer lays in being flexible. We are talking about developers being the end-users in this case. The more flexible the solution can be, the better it can be utilised for your particular need. All the way from warnings being given at compile and producing r-code to... strict errors and no r-code.
The more flexible the better, but that's also up to the Progress developers to see what issues it causes in their code....
We all want to promote good coding practices... so the defaults can always be setup to promote this.
I've already expressed my opinion during the ESAP, an error-only mode is not possible when working with legacy code (so basically anything written before the strict mode compiler).
From a developer perspective, having to fix all abbreviated keywords or table names before being able to do anything on the code is a blocker problem.
From a continuous integration perspective, I've solved nicely the problem with Ant / PCT and SonarQube to track all those strict mode errors.
Whilst I agree that in theory nobody should have ever abbreviated anything, the fact is, they have. For whatever reason. Whilst I want to encourage developers to fix the code, I don't want to build a situation where I can't compile code to ship to a customer. Therefore having the option to produce rcode if the only errors are strict compile errors would be a big benefit.
Yes you could probably work around the issue with different compile operations depending on requirements, but why should I have to?
I'll echo the opinion that it's the developers that should get the option to control if breaking a strict rule is a warning or an error condition, for reasons that others already mentioned above.
Further, you may want to enforce some options more strictly than others, so being able to set this per option would be nice.
Something like "require-full-names:E , require-field-qualifiers:W require-full-keywords:E" -> E = error, W = warning, similar to how log entry types allow overriding logging level for that specific type.
In my opinion this should be configurable.
Although the ideas being put forward for extending the feature to allow sub-options that allow either errors and warnings are good, the discussion here is how we handle this in the immediate future.
The 11.7 release will be the long term support for OE 11. We are now getting started on 12.0. Since there will be no more major changes for 11.7 in the service packs, we do not have the option of making a major feature upgrade there. Thus, this question is how to address this most simply as possible. For OE 12 we will be focusing on getting new options suggested by Community implemented and may not consider the sub-option concept for quite some time.
So, excluding additional changes, what do you see as the preferred way that we handle it. Shall we default to errors and no r-code as it is now, or would you prefer that we generate only warning and produce r-code.
Some of the earlier discussions are on the ESAP Community. I don’t know if the ESAP posting are open to the public at large, so those not on the ESAP Community may not have access to them. So go ahead and repeat earlier arguments if you feel strongly enough about them.
The ESAP postings are only open to the folks in the ESAP group, so not public.
To answer your question, Alex, in my opinion it is imperative to be able to produce rcode if the only errors are strict compiler ones, so downgrade to warnings please.
Alex, if the compiler can ‘digest’ the s**t there is no reason not to generate r-code - I don’t think there is anyone out there that would like to be either forced to fix all warnings or simply shift them all together, time constraints will make the second option be the only valid choice anyway :(
[quote user="Alex Herbstritt"]
Although the ideas being put forward for extending the feature to allow sub-options that allow either errors and warnings are good, the discussion here is how we handle this in the immediate future.
The 11.7 release will be the long term support for OE 11. We are now getting started on 12.0. Since there will be no more major changes for 11.7 in the service packs, we do not have the option of making a major feature upgrade there. Thus, this question is how to address this most simply as possible. For OE 12 we will be focusing on getting new options suggested by Community implemented and may not consider the sub-option concept for quite some time.
[/quote]
Alex - this kind of bureaucratic language has no place in Progress's operation. We are not talking about a "major change" here, we're talking about adding a check on an element of a CSV string for :ERROR or :WARNING, setting a flag, setting the flag to a default value if the :ERROR / :WARNING is not present, passing that flag to the compiler, and have that control the compiler's behavior.
You guys messed up my mandating a 'one-size-fits-all' instead of implementing a configuration setting, and rather than fixing the mistake correctly you're asking if we want to make a different mistake by imposing a different one-size-fits-all that will eliminate the possibility of mandating that strict compiles are an absolute requirement in the future.
One-size-fits-all was the wrong decision before FCS, it's the wrong decision now, and you need to fix it instead of mandating a different bad decision.
The correct decision is to give the developers control of the behavior whether it's via an ERROR and :WARNING flag or some other mechanism.
I agree with Tim that it *should* be up to the user.
But if I must choose one or the other in the short term then I would go with "warnings". My thinking is that early adoption would be more likely that way.
Tom - the issue is this isn't a 'short term' decision - Alex stated that whatever they do will be it for the foreseeable future past when 12.0's release.
If the decision is error-only, then this becomes useless for larger, long-lived code bases. Cleaning these code bases of these issues would require significant developer effort - or the use of an automated tool that doesn't exist yet (as far as I know).
If the decision is warning-only, then each site that wants to mandate strict compile as an absolute requirement will have to write code to catch these warnings and implement their own "error-only" behavior as opposed to simply changing a string setting.
An error-only decision means a good idea won't get used where it's needed the most.
A warning-only decision means the customer base will need to collectively expend a significant amount of time in order for Progress to save a bit of time on their side.
Peter - there is no appropriate "one size fits all" solution which is why mandating either one or the other is a bad decision. Furthermore, for PSC to state that it will be one size fits all past the release of 12.0 (and potentially for the foreseeable future) significantly raises the stakes on what is done now.
I love that the feature's been added, I look forward to using it, what I need from Progress is the ability to use it as circumstances dictate w/out having to write more code to get something I should've gotten out of the box.
Okay, so the discussion has simmered.
The real answer is that Community wants both. Or, more to the point, control over it.
Instead of rushing a change into an early 11.7 service pack I am going to take a look at implementing something along the lines of the sub-option described here in 12.0. We will leave 11.7 alone for now and see what we can put together for 12.0. Then we can consider porting something to 11.7 in a service pack. I am making no promises here! We may leave 11.7 alone, we may downgrade to warnings, or we my port the 12.0 changes (if they happen).
I will try and get a pseudo-specification for 12.0 posted here this weekend.
I got an email saying Alex had posted an update here - and I'm not seeing it. Has it gone into stealth mode?
I saw it in a prior email, not here though.
Sorry for the multiple posts. Community seems to be having some technical problems. I will copy/paste one more time and then contact somebody about the site.
Community overwhelmingly wants both, so instead of rushing a change into an early 11.7 service pack I am going to take a look at implementing something along the lines of the sub-option described here in 12.0. We will leave 11.7 alone for now and see what we can put together for 12.0. Then we can consider porting something to 11.7 in a service pack. I am making no promises here! We may leave 11.7 alone, we may downgrade to warnings, or we my port the 12.0 changes (if they happen).
I will work on a pseudo-specification for 12.0 and post something about it soon.
Now we have 3 Alex answers! :)
With respect to features not changing once they're released - there is precedent for changing or reverting feature behavior that caused the user base an issue.
With respect to what to do now - I'd be fine with having the default behavior be error-only **if** you added a sub-option to enable changing the compiler response to a warning.
Error as default will encourage good code writing in the future.
Warning as an option will enable large-code-base shops to progressively work through their code base and do a strict compile to an error on files that are clean so they stay that way, and a strict compile to a warning on files that still need work.
Alex:
Eliminating all abbreviations or changing other code that was working and acceptable practice in an existing code base costs money. Possibly a /lot/ of money in some partner's applications.
If a release forces such activities, it will be a huge barrier to adoption.
If a release forces such activities, it will be a huge barrier to adoption.
Of course, the release is not forcing ... one can always just decide not to use these new compiler options. I would think it likely that many people will have code bases and budgets such that they will not target this kind of cleanup because it is simply not a priority. In particular, any end-user of an ISV's package which is full of these issues will not want to use the options because they don't want to change the ISV's code except in those places where they are making a functional change.
So we are going to go ahead with adding the warning/error sub-option to the options for 12.0.
We did consider this when we were designing the feature but chose not to implement it with the initial release. Believe me, we have talked about this quite a bit.
We will change the default message level to warning, and add the sub-options to all three options.
Take a look at the COMPILE OPTIONS phrase
/* COMPILE procedurename.p OPTIONS "option[:level] [,option[:level]] ..." */
COMPILE procedurename.p OPTIONS "require-full-keywords, /* Defaults to Warning */
require-full-qualifiers:Error,
require-full-names:Warning."
And the COMPILER:OPTIONS attribute
/* COMPILER:OPTIONS = "option[:level] [,option[:level]] ..." */
COMPILER:OPTIONS = "require-full-keywords, /* Defaults to Warning */
require-full-qualifiers:Error,
require-full-names:Warning".
This will also be valid from within the options-files for the OPTIONS phrase and the startup parameter.
Again with the disclaimer: just because I said it here does not mean it will be there or this way in the final release.
Looks good to me! Thanks for the update!
I don't think, that it is a good idea to change the default behavior of a released feature.
As part of the 1st ESAP for the 12.0.0 release, it is now possible to associate a severity level (error or warning) with each Compiler Option you identify. Additionally, the default severity level is to generate a warning and not to cause the compilation to fail – as was done in 11.7.0. The 12.0 ESAP contains a preliminary version of this feature as well as associated documentation.
Based on the community input, the Core Client team will investigate back porting this work to an 11.7 service pack and therefore the team would appreciate your feedback on this feature and its documentation.