In our previous episode, Michael Schnell said: > 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.
I don't really see it. I'm not even sure if I would like it, even if there was no Delphi compatibility to consider. > But what do you mean by "fork" regarding the compiler and RTL (which > would be the prerequisite for any decent LCL implementation). Well, since the choices for FPC have been made, you were working on your own version, a bit like MSEGUI's Martin Schreiber? > 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. It is necessarily, since you must show it can actually work. Since you want a decision as much as possible, I wouldn't work in a branch but in a separate fork, and just hack it to run on say Linux and Windows. Just as a proof of concept. If you have a working proof of concept it is much easier to convince people to give it a go. Much easier than with just two paragraphs of descriptions fragmented over 250 unicode discussion messages. > 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) single source two releases, or two source two releases? _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
