[Lazarus] Beyond Compare 4 built with Lazarus 1.2

[Marcos Douglas]

On Thu, Dec 26, 2013 at 6:06 AM, Martin Schreiber <mse00000 at gmail.com> wrote:
>
> On Thursday 26 December 2013 03:45:19 Marcos Douglas wrote:
> >
> > "As long as the language and libraries agree on an encoding I don't
> > really care whether it's UTF-8 or UTF-16"
> >
> > +1
> >
> Actually this is the MSElang approach. MSElang supports "string8"
> (utf-8), "string16" (utf-16), "string32" (UCS4) and "bytestring" which can
> hold any 8-bit encoding or binary data. There is no "string" type defined in
> MSElang and there are no implicit type conversions in MSElang.
> "
>  floatvariable:= floatvalue + integervalue;
>  string8variable:= string8value + string16value;
> "
> will not work and must be written as
> "
>  floatvariable:= floatvalue + float(integervalue);
>  string8variable:= string8value + string8(string16value);
> "

You mean won't compile or raise an exception at runtime?

> The compiler then will do the conversions.
> The MSElang RTL is the bare minimum, most of the functionality (lists, file
> API...) is implemented in an optimized manner in the framework, in MSEgui for
> example, which already does not use much of the FPC RTL or - in a
> hypothetical case - in LCL. ;-)

But what is the string type of MSElang RTL? If it will use string16
and my application uses string8 I will need to use conversion all the
time, like SysToUTF8/UTF8ToSys functions... no?

> Every framework can use the stringtypes it likes, common RTL parts could be
> made in collaboration between the frameworks. Because MSElang compiler
> supports all without preference and the framework development does non need
> to wait on implementation decisions on complier or base-RTL level the
> development can be accelerated.
> It is apparent that such an approach is very unfeasible for a commercial
> compiler manufacturer because the loose of control. I assume that the Delphi
> architecture has been carfully chosen in order to maximize the control over
> the ecosystem.
> But for an opensource undertaking the MSElang principle could work. :-)

Automatic conversions is good.
IMHO should exist a global variable that have the default codepage --
MSE is string16 -- and the user can change.
The compiler needs this variable to use the default encode when the
user concatenate two or more strings with different encode. So, RTL
can be string16, apps string8, Windows API string16, whatever... but
the compiler will convert all calls automatically.

Marcos Douglas