On Mon, 11 Mar 2019, Bart wrote:
On Mon, Mar 11, 2019 at 12:37 AM Michael Van Canneyt
<mich...@freepascal.org> wrote:
What's the problem ?
The problem is that you make me feel that evreything I do or think of is wrong.
Sorry to hear this.
That was certainly not my intention, on the contrary: I am glad to see that
someone takes the time to look at some of these bugs in earnest.
Most likely this would not be the case if we were in the same room and
talked about it.
I share your point of view on this :)
Another practical problem is that we (as in the participants in this
thread) still have not decided which way to go with this.
Do we want overloads for all public/protected TRegistry methods that
use UnicodeString or Utf8String, or both, or none of that?
From my perspective: the public API is all that matters.
There I would opt for overloads that accept unicodestring.
People that need unicode use those, people that use ASCII (or ANSI) use the
'old' ones.
The current solution of trying to squeeze Unicode in UTF8 apparently creates
more
problems (or at least discussion) than it solves.
For organizational reasons, I personally prefer a single patch that
implements what I consider correct, and not a series of incremental
patches each addressing part of the problem.
I understand that, but ATM it is almos undo-able for me to work on the registry.
Every time I work on one issue I have to revert all chages I made for
other issues.
This becomes very cumbersome, very fast.
If I start writing the "all including" unicode patch for TRegistry it
will include unrelated fixes, otherwise I cannot test what I'm doing.
Fine with me, but I cannot speak for the other devs.
As long as it results in a working TRegistry class.
Just clearly mark what bugs it is supposed to fix.
There are tests for TRegistry checked in. If they don't complain, all
fine...
IMO, since this is trunk, patches need not be perfect in order to be
apllied, they just need to be better than the old situation.
Of course judging that is up to the devels.
Apply and then gradualy better the code based on feedback.
Once "good enough" merge all fixes to 3.2 branch.
This is probably the approach the other devs would like to see :)
Another problem for me is the not-windows part of the registry.
E.g. TRegIniFile in the XML implementation is totally broken for at
least 6 years.
Nobody has posted a bugreport about that in that period.
Probably because no-one in his right mind uses TRegIniFile ?
TRegIniFile is a component from Delphi 1 or 2, to facilitate the transfer
from ini -> registry which was relevant in 1995 or thereabouts.
Maybe we should simply ditch it, or move it to a separate unit and mark it
deprecated.
Now that comes to bite me in the *** when I fix some bugs in the
windows implementation of TRegIniFile.
Fixing the XML implementation of that is currently beyond my capabilities.
(In my personal opinion I'ld get rid of the not-windows implementation
of TRegInifile. Yes it is backwards incompatible, but there cannot be
users out there using it, otherwise bugreports would have been filed.)
See above.
So, please carry on. Someone will eventually apply the patches!
I will try to.
B.t.w. Michael: you unassigned yourself from
https://bugs.freepascal.org/view.php?id=35213 and
https://bugs.freepascal.org/view.php?id=35022 , but you forgot to
change status to either new, acknowledged or confirmed. Now the issues
are still "blue" in the bugtracker, so every other devel will think
the issue is assigned to some other devel.
Can you please adjust the status of the issues?
I did so.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
