[fpc-devel] Unicode proceedings

[Marco van de Voort]

In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 11/16/2011 10:44 AM, Marco van de Voort wrote:
> >
> > It's a mix of all three actually. It is typed(A), there are two (B)
> > implementations, and the memory layout of both implementations have
> > similarities that makes Rawbytestring possible, making rawbytestring the
> > base memory representation the others "inherit" from (C).
> >
> > Finding (C) is a bit of a stretch though. A and B are way more true than C.
> What do you mean by "true". If you mean "it's more true that Delphi 
> works similar to that"

Yes, and FPC/trunk.

>  the question, is if it is really a good design 
> goal to do an implementation that is closest possible to what DXE 
> provides, regarding that (from what I read, I don't have XE to test it) 
> the XE definitions to me seem like a rather chaotic and hardly 
> understandable mix of strong typing and dynamic encoding.

Then reread the discussions on the list about unicode. In the past few years
it has been explained enough. And before D2009 came out there was a lot of
discussions about how we would tackle it if it were a black slate.

Then there were fully dynamic encoding schemes proposed too (e..g by
Florian).

> > A is from the type system view.
> Yep: no dynamic typing. (As there is no dynamic encoding this obviously 
> is not at all Delphi XE compatible, neither regarding the definition nor 
> regarding the implementation.) A RAW type, allowing for multiple 
> encoding types, is not possible here.

Correct. See the discussions mentioned above (say roughly march-may 2008)
for more info.

> > B is from the implementation (runtime
> > helpers) view.
> Nope it's just a definition of a pure dynamically typed string 
> definition system. Implementation details were only mentioned to try to 
> make clear what I meant. (As there is only one String type and there is 
> no way to have the name of a type denote the encoding, this  - regarding 
> the definition - obviously is not at all Delphi XE compatible.)

I'm not sure what you meant. I only saw what you wrote. You created three
classes of stringtypes, but in reality the implementation is hybrid of the
first two (the (C) bit was a bit a joke, since rawbytestring is so limited)

> > C only for rawbytestring (which is very, very limited and way
> > overestimated in all these discussions)
> >
> Nope. C defines the other new types as object-alike children of a 
> general "RAW" type.

As far as I know C has no object type. What you want with the whole (C)
branch is a complete mystery to me. That's mostly caused because you
describe proposals with very general terms like "OO" and "paradigm" and
vague references to other languages.

If you want to make proposals, make them clear, self contained, to the point
and coherent, see also

http://www.freepascal.org/faq.var#extensionselect