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?
conversion of identifiers between Unicode and Utf8
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: conversion of identifiers between Unicode and Utf8
I am not suggesting to change Strings now!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 do not want to inhibit this possibility by the initial design.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: conversion of identifiers between Unicode and Utf8
I already regret that I have started this discussion and I actually didn't wantZinn 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?
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
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: conversion of identifiers between Unicode and Utf8
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.
I am able to fix this bug and process it, so please do not do this work for me now.
I do not like idea about changing the issues number. What about my compromise suggestion? You did not answer.
For me there is not problem to make new branch or new issue. I fill comfortable with current pipeline we developed.Ivan, if you like, I can do the editing in your name. Its a matter of minutes only.
I am able to fix this bug and process it, so please do not do this work for me now.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: conversion of identifiers between Unicode and Utf8
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.
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.
Re: conversion of identifiers between Unicode and Utf8
I think I'm repeating myself: then it should be seperated out into another module, which is imported by Kernel.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 do not think that importing Kernel should be done without any important (!) reasons ....
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: conversion of identifiers between Unicode and Utf8
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.
Re: conversion of identifiers between Unicode and Utf8
with this argumentation you end up with too many modules importing Kernel ...
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: conversion of identifiers between Unicode and Utf8
No.bernhard wrote:with this argumentation you end up with too many modules importing Kernel ...
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
Re: conversion of identifiers between Unicode and Utf8
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.
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.