Small TdwsMessageList enhancements

[Dennis Göhlert]

Hey, would it be possible to add the following (minor) changes to the TdwsMessageList class? Currently, working with it is a real challenge in some ways, and this could be changed quite easily.

• Add Enumeration support for FOR-IN loops to iterate messages

• Add an OnChange or (OnAdd at least) event

• Add a localization option to localize messages or parts of them

• There seemed to be some problems when multiple messages were in the same line in earlier versions. I do not know if this had been fixed yet. If not, this would be important.

Thank you Eric and best christmas wishes from Germany! ;)

-Dennis, SMS team

[Eric Grange]

Enumerator added with latest commit.

At the moment the TdwsMessageList is not really meant to be accessed during compilation, and after compilation, it should not change. What would you use the OnChange event for?

To localize compiler messages, you can replace the "const" with "resourcestring" in dwsStrings. Though I am not planning to support localizing compiler error messages, because it makes support very complicated when localized error messages are reported, and localized error messages are very commonly misleading. I suffered through that with french Delphi a decade ago, and I personally will not ever install a compiler with localized error messages again :)

Compile-time localization of source code text is supported through 'resourcestring' and gettext-similar underscore function, f.i. _('localize me'). Runtime localization support in JS codegen has not been implemented yet, though it would just be a matter of choosing a localization approach/library, and then adapting TJSGetTextFuncExpr.CodeGen accordingly.

[Dennis Göhlert]

Thank you already for this. About the OnChange event: My intention was not to "change" it myself, my intention was to track changes using an OnChange event, just like a TStringList offers this. Why should this not be possible?

[Eric Grange]

Mostly because the flow goes as follow: 1. compiler creates TdwsMessageList (not externally accessible, ie. so you cannot set OnChange) 2. compiler fills up TdwsMessageList, with no promises about linearity, structural aspects or implementation details 3. compilation ends, IdwsProgram is delivered and TdwsMessageList is accessible (but won't change anymore, so OnChange will never fire)

So an OnChange would only make sense if 2 was changed, and "promises" were made about compiler internals on how TdwsMessageList is filled up during compilation. Currently making no promises about step 2 means the following are possible:

• adding messages to the list before all their properties have been set or finalized
• having later compilation stages alter or remove previous messages (f.i. see RemoveInvalidDeferred)
• having multiple messages lists during compilation that are later merged (in the repo, you can see this done for the JS Filter)

All the above mean that the code in an OnChange event could not do much that would be "safe" or meaningful (even the message count isn't guaranteed to increase linearly)

[Dennis Göhlert]

Oh, okay. Thanks for this clearification... I did not know it was this "untidily"-filled. Thanks however for the reply. Just a side note: the enumerable-stuff you added to the class is not yet supported by the DWS language, yet, is it?

[Eric Grange]

No, GetEnumerator is not supported yet.

I added an issue #123 to remember it