[Lazarus] Beyond Compare 4 built with Lazarus 1.2

[Marcos Douglas]

On Fri, Dec 27, 2013 at 6:21 AM, Martin Schreiber <mse00000 at gmail.com> wrote:
> 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.
>> > [...]
>>
>> 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.

IMO your thinking is correct: simplify things, codify the minimum
necessary, encapsulate others things. But you are constructing a "new"
compiler, for your framework... you don't care about Delphi, LCL, etc
-- I think FPC+LCL should not follow Delphi too but this is not the
real world today -- and these things simplify the implementation.

You said File API is not part of MSElang RTL... so I will need to codify my own?
This is not wrong but I think there should be a default implementation
for these things... anyway.

>> > 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 the major problem is follow Delphi...

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

Resume:
MSElang do no allow to cancatenate different string types (must be
explicitely converted) and the RTL does not will use string8.
So if I want to use Lazarus (LCL) with MSElang I will continue to have
the need to convert all call from/to MSElang RTL because they have
different encode. Is that right?

Regards,
Marcos Douglas