On 02/28/2014 02:26 PM, Marco van de Voort wrote:
I think it is better to start implementing it in a fork. A fork can
move much faster and make a reconnaissance of all problems and find
solutions for them, and see what you can do to improve compatibility.
One the fork has a functioning Lazarus again, you will have a much
better bargaining position than now while it is all paper, and some
people are strongly in favor, and the others say it won't work.
I see that trying different kinds of "Delphi compatibility plus
OS-independence" (which obviously is a contradiction in itself) makes a
lot of sense for the fpc / Lazarus combination.
But what do you mean by "fork" regarding the compiler and RTL (which
would be the prerequisite for any decent LCL implementation).
A) Doing a "Generic" (fully dynamically encoded) String type.
Here, IMHO regarding the compiler a fork is not necessary, as this is a
pure addition. If you don't like it, just don't create any string with
that type. Defining the type of TStrings (and some other RTL introduced
objects and functions would be a simple "ifdef" thingy. Of course the
implementation of the functionality is mostly a pure addition, as well,
as the actual type needs to be detected and handled appropriately (easy
with TStringList, but potentially complex for stuff like TMemo, no idea
(yet) with pos(), copy() and friends).
B) another idea of forking on behalf of Lazarus could be to do a "Delphi
compatible" branch with a completely UTF16 based RTL (and compiler
magic) and a "Lazarus compatible" branch with a completely UTF8 based
RTL (and compiler magic)
-Michael
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
