issue-#29 inconsistent checks for valid subsystem names

[Bernhard]

Dear Ivan,

for me this is some variable with POINTER TO RECORD type which has method Do!
However now it can be subsystem some with module Thing with PROCEDURE Do*();

hmm, yes, but that is convention and I consider it as "good practice" to start a module name with a capital letter, but I don't like to be forced to do it.

There are some guidelines in "Programming Conventions" Sec. 8.

I think we should add a note there about subsystems and their naming ...

Currently I am a bit puzzled how cyrillic or greek subsystem/module names behave since these are possible with issue-#19.

The pathological case "MODULE ___Abc; ... END ___Abc." is handled correctly by the compiler.
--
Bernhard

[Josef Templ]

Cyrillic and Greek work fine with subsystems because they have uppercase and lowercase letters
very much like Latin has.
Actually, the ONLY problem is with Japanese Hiragana and Katakana character sets
because they do not have this distinction. This causes also some troubles in Kernel.IsAlpha,
which is passed on to Windows, because, surprisingly, only characters that are either
uppercase or lowercase are considered as 'alpha'-characters under Windows.
There has been a discussion on the community forum about that and there
is a smart and efficient proposal how to solve the issue in Kernel.IsAlpha.
cf. http://community.blackboxframework.org/ ... t=japanese.

- Josef

[Ivan Denisov]

With the changes in issue-#29 the modules DevSubTool and DevLinkChk stick to the rules
enforced by the compiler and loader. At least this was the intention.
In addition, the minimum length of 3 characters is enforced by DevSubTool.
In my opinion, it should be changed to a warning. There should also be a warning for
subsystems that start with a non-uppercase character.
In DevLinkChk there is no need for such warnings because it does not create
new subsystems but operates on existing ones.

According this logic such limitation should be reduced. I agree with that. The warning can be made with GetOK dialog.

However if we will look at the Python experience (the most used language of our days), the strict tabulation increasing the readability of code. So if we will fix the conventions in strict rules (the framework will help to lead the conventions), we will make good work.

I have other question about DevSubTool, why after it generates three modules according last option them do not compiling successfully?
For example, if I will make the "Test" subsystem and try to compile TestViews.

Code: Select all

PROCEDURE (v: View) ThisModel* ():  TestModels.Model, EXTENSIBLE; END

In this line there will be an error "the function without RETURN". Can somebody explain what does mean "covariant narrowing of function result" ?

[Josef Templ]

> Can somebody explain what does mean "covariant narrowing of function result" ?

This means that the type of the result of the specialized function
is a specialization of the result type of the corresponding function in the base type.
'covariant' here means that both types are specialized.
The receiver type is specialized and the function result type is also specialized
compared to the overridden function in the base type.

- Josef

[Josef Templ]

I found two entries named 'CannotTranslate in Dev/Rsrc/Strings
and removed the first one, which is overridden by the second one anyway.

The check for a minimum subsystem name length of 3 characters and for a leading
uppercase character are now warnings in DevSubTool.
Dialog.GetOK is used for creating the warnings and the user can respond with OK or Cancel.
In order to be consistent with the warnings and to make error messages more visible,
I have used Dialog.GetOk also for error messages instead of writing to the log window.
Here are the diffs: http://redmine.blackboxframework.org/pr ... bfa40ec0a1

Otherwise, the behavior of DevSubTool is completely unchanged.
It is a rarely used feature anyway, I guess. At least I did not even know it
until starting this issue.

I think the topic branch is in a good shape now and ready for voting.
Any comments?

- Josef

[Ivan Denisov]

Josef, I tried and like how it works. However maybe better to use "Yes" "No" buttons instead of "Ok" and "Cancel"? And put a question after Warning message "Would you like to continue?".

[Josef Templ]

Yes/No is certainly also possible, however I tried to keep the required Strings resources
as simple as possible (no multi-line warning text; as few entries as possible).
OK/Cancel expresses implicitly that the command can be terminated at this point.
For a rarely used feature I think this is enough. On the other side I have absolutely
no problem with changing it to Yes/No if the center prefers it.

- Josef

[Ivan Denisov]

During the first try this "Ok" and "Cancel" were not obvious for me... maybe because I am not native speaker.
Usually "Cancel" is just closing modal dialog and not aborting the operation. "No" is more clear for stopping of subsystem creation.

[Josef Templ]

> During the first try this "Ok" and "Cancel" was not obvious for me... maybe because I am not native speaker.
OK, now it should be clear.

BTW, look for example at the situation where you close a changed document.
You get a dialog box saying that the file has been changed and "Do you want to save the changes? Yes/No/Cancel"
With Yes/No you decide how the command proceeds, with Cancel you stop it.
It is assumed implicitly that you know what Cancel means in this context without an extra text for it.

For our purpose it should be more than enough to have the warning with OK/Cancel.
It is a rarely used feature anyway and rarely^2 used warnings.

- Josef