On Fri, Dec 27, 2013 at 6:21 AM, Martin Schreiber <[email protected]> wrote: > On Friday 27 December 2013 02:36:22 Marcos Douglas wrote: >> On Thu, Dec 26, 2013 at 6:06 AM, Martin Schreiber <[email protected]> >> > 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
