BlackBox Framework Center

Why I changed my mind (vote)?
The reaeon is:
I won't have different implementation of Utf8 conversion inside Kernel & Strings.

Personally I prefer to use Kernel for all translations of identifier,
because Kernel is imported by those modules anyway.
Why should I import Strings too?

Zinn wrote:Why I changed my mind (vote)?
The reaeon is:
I won't have different implementation of Utf8 conversion inside Kernel & Strings.

Personally I prefer to use Kernel for all translations of identifier,
because Kernel is imported by those modules anyway.
Why should I import Strings too?

I am not suggesting to change Strings now!
I do not want to inhibit this possibility by the initial design.

Zinn wrote:Why I changed my mind (vote)?
The reaeon is:
I won't have different implementation of Utf8 conversion inside Kernel & Strings.

Personally I prefer to use Kernel for all translations of identifier,
because Kernel is imported by those modules anyway.
Why should I import Strings too?

I already regret that I have started this discussion and I actually didn't want
that we change a lot of modules now. It was originally only about a cosmetic change in DevBrowser
but turned into a lengthy discussion that kept us from more important work.

Since the currently applied style seems to be that Strings is used in modules
that don't import Kernel anyway (e.g. DevCPT, DevCPP) and Kernel is used in modules
that import Kernel but not Strings, I can also live with Kernel in DevBrowser
but I would certainly not introduce an import of Kernel in DevCPT and DevCPP.

The more important thing is to move it to #19 and get rid of #57.
This should really not be in the redmine issue list because it is not a change from 1.6 to 1.7
but an internal split into several merges due to an oversight.

Ivan, if you like, I can do the editing in your name. Its a matter of minutes only.

- Josef

First of all, this voting is not over. We need two more votes for quorum or "short circuit".

I do not like idea about changing the issues number. What about my compromise suggestion? You did not answer.

Ivan, if you like, I can do the editing in your name. Its a matter of minutes only.

For me there is not problem to make new branch or new issue. I fill comfortable with current pipeline we developed.
I am able to fix this bug and process it, so please do not do this work for me now.

One more argument came today. Maybe you will find it reasonable.
Can you imagine that for some problem which are spread for several modules you are using different modules for one task? You encode by one module and then decode by another... Let's be mathematically strict. The module is the unit of compilation and it can be exchanged in the system. Encoder and decoder should not be in separate modules. So, if for some modules Kernel should be used, it is necessary to use it everywhere for identifiers compatibility.

Ivan Denisov wrote:One more argument came today. Maybe you will find it reasonable.
Can you imagine that for some problem which are spread for several modules you are using different modules for one task? You encode by one module and then decode by another... Let's be mathematically strict. The module is the unit of compilation and it can be exchanged in the system. Encoder and decoder should not be in separate modules. So, if for some modules Kernel should be used, it is necessary to use it everywhere for identifiers compatibility.

I think I'm repeating myself: then it should be seperated out into another module, which is imported by Kernel.

I do not think that importing Kernel should be done without any important (!) reasons ....

Any identifier call, compilation or debug message are low-level runtime operations and it is important reason to use Kernel if this identifier need to be converted. Usage of separate module is only complicating the framework. The runtime now can not "live" without such converter, so it can be included in Kernel.

with this argumentation you end up with too many modules importing Kernel ...

bernhard wrote:with this argumentation you end up with too many modules importing Kernel ...

No.

This rule will require only three modules to import Kernel:
Dev/Mod/CPS.odc
Dev/Mod/CPT.odc
Dev/Mod/CPP.odc

Other modules with identifier conversion already importing Kernel for other purposes:
Dev/Mod/Debug.odc
Dev/Mod/HeapSpy.odc
Std/Mod/Debug.odc
Dev/Mod/Browser.odc
Dev/Mod/CPM.odc
Dev/Mod/Analyzer.odc
Dev/Mod/Compiler.odc
Dev/Mod/Dependencies.odc
Dev/Mod/Linker.odc
Dev/Mod/Profiler.odc
Std/Mod/Loader.odc

Is it possible to change one's vote?

This is obviously an important issue for some people, and I have not followed the discussion closely enough to make an informed decision, so would like to abstain.