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); " 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. ;-) 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. :-)
Martin -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus