[Lazarus] Beyond Compare 4 built with Lazarus 1.2

[Martin Schreiber]

On Friday 27 December 2013 02:36:22 Marcos Douglas wrote:
> On Thu, Dec 26, 2013 at 6:06 AM, Martin Schreiber <mse00000 at gmail.com> 
> > 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?
>
Will not compile.

> > 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?
>
There will be not many functions with strings in MSElang RTL, most of them 
will be moved to the framework. BTW somebody can write a Delphi compatible 
framework-RTL if desired.
The remaining string routines (mostly string comparison and the like) will 
have overloaded versions for "string8", "string16", "string32" and 
maybe "bytestring". Bytestring will assume 8-bit encoding of the current 
locale.
RTTI will use "bytestring" with pure ASCII. If tcomponent (or its equivalence) 
is part of MSElang RTL (not yet decided), component names and the like also 
will use "bytestring" with pure ASCII.
File API is not part of MSElang RTL.

> > 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.

I don't think so. One easily can see how problematic automatic type conversion 
is. It actually stalls Free Pascal development since several years. It is 
seldom used, to type the conversion functions in code is not a big deal and 
helps to identify problematic designs.

> IMHO should exist a global variable that have the default codepage --

It is not necessary. Because MSElang does not define and does not know the 
type "string" one can define "string" oneself or it is defined in the 
framework. 
Lazarus probably will write
"
type
 string = string8;
"
Although I would recommend to replace all GUI "string" types by "lazstring" 
and to define
"
type
 lazstring = string8;
"
> MSE is string16 -- and the user can change.

MSEgui will not use "string". What is currently "string" in MSEgui will be 
changed to "bytestring". GUI strings will remain "msestring". Filenames will 
remain "filenamety".

> 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.
>
MSElang does not allow to concatenate different string types, they must be 
explicitely converted.
"
 string8var:= string8value + string8(string16value) + 
       string8(bytestringvalue1) + //assumes encoding of the current locale
       cp1251toutf8(bytestringvalue2); //uses conversion function,
                                       //not part of MSElang RTL
"

Martin