[fpc-devel] Unicode proceedings

[Michael Schnell]

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" 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.
> 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.
> 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.)
> 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. Here we have as well a "RAW" type, as multiple types 
the names of which suggest a certain encoding the definition. This seems 
to be rather similar to Delphi XE's. The implementation might be done 
compatible to what XE does, but the intention of my post was to suggest 
that _first_ a decent (strict, understandable, unambiguous) definition 
should be done (as "Delphi-XE-compatible" does not seem to provide an 
understandable straight forward wording) and _afterward_ evaluate the 
implementation (i.e. take a look at doing how to improve what already 
has been done).

-Michael