[Lazarus] rewriting of LConvEncoding

[Guy Fink]

> > I want to contribute to the project with my knowledge of more than
> 20
> > years programming in Pascal (since the very first days of Turpo
> Pascal).
>
> ahhh... another oldtimer amongst us :P

:P yes, the good ald times, Turbo Pascal on 1 floppy, and the sources on the 2nd :-) and there was this 64KB limit (yes 64, not 640) *g*

> that would depend on the "fix" wouldn't it? it also depends on
> the core
> "guidance team" and if they accept the fix... remember one
> goal is to not break
> existing functionality... maybe your fix/enhancement would/should use
> different
> unit and include names so as to not break what's already being used in
> thousands
> of projects? that way the core team can bring it in gradually and/or
> existing
> projects can convert to it on their time and needs ;)

Thats what I have in mind. It is clear that existing projects should continue to work...


> > Is that really a reason not to start support for it? I don't think so. I even
> > think it is a reason to support it, Delphi does not have full Unicodesupport,
> > FPC will have.
>
> one must also remember and take into account that delphi compatibility
> is a
> goal... that FPC and Laz have the option and ability to move further
> than delphi
> is a plus but delphi compatibility is still a requirement...
>
> and what happens when delphi does add such capability? will your
> fix/enhancement be "updated" to match delphi?

Why not? But as long as Delphi does not have the capabilties, why should we restrict ourselve?

> > UTF32 is there in the world, and yes it is wasteful.. And so what?
> Is that a
> > reason to ignore it?
>
> on the surface, i'd say "no" but another question that comes
> to mind is why invest time in it if it goes nowhere?

If you support UTF16, UTF32 is really not a great investment, neither in time nor in resources.


> > These routines do not support all of the codepages. Further, the aim of a
> > library is not to wrap some OS routines but to deliver functionality to the
> > developer to help him solve his problem. Developers need solutions, not good
> > words of how clean and ligthweigth the libraries are.
>
> i tend to agree with this, on the surface... however, much is actually
> done by
> providing wrappers so that existing functionality and compatibility can
> be  maintained...

Adding functinalty does not mean that existings things have to been throwne away.


> >>> With static tables, I mean a table in a const-section,
> compiled and
> >>> linked into the code.
>
> one must remember that FPC's and Laz's smartlinking stuff is nowhere
> near like that in TP/BP or delphi... but i'm also not sure if that fits with what
> you are saying, either...

Ok, but you agree that it is easier for the compiler to optmize access to an array of WORD or DWORD, with a known size at compile time, than to a linked list of dynamic arrays of some record type?



______________________________________________________
powered by GLOBER.LU
Luxembourg Internet Service Provider
Hosting. Domain Registration, Webshops, Webdesign, FreeMail ...

Our professional Web Hosting plans include all the features you are looking for at the best possible price.
www.globe.lu