[fpc-devel] Unicode proceedings

[Michael Schnell]

On 11/16/2011 11:36 AM, Marco van de Voort wrote:
>
> Then there were fully dynamic encoding schemes proposed too (e..g by
> Florian).
I do know this. There seems pros and cons have been discussed, but no 
real decision has been done (i.e. a strict independent understandable 
definition of what is supposed to be provided from the view of the user 
- not from the view of the implementation).
> 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)
Sorry if I have not been clear enough. I suggested three (mutually 
exclusive) alternative ways to define a (supposedly clearly definable 
and workable) family of String types (OK, "B" suggests a 
one-member-family).
>
> As far as I know C has no object type.
Correct. That is why I wrote "object-alike". This wording only 
illustrates that there is a kind of Parent-Child relationship between 
the RAW string type and the types supposed to hold a specific encoding. 
With this in mind, it is obvious that when a function uses a "RAW" as a 
parameter, no conversion is done, as RAW "is" any specific String type.
> What you want with the whole (C)
> branch is a complete mystery to me.
Obviously a single fully dynamically encoded string type (such as B) is 
not what everybody (but Florian an myself) wants, (e.g. because EMB 
decided implementing multiple types with different names).

Obviously a system of hard coded string types (such as A) is not what 
everybody (but some) wants (e.g. as there would need a lot of such types 
and because EMB decided implementing dynamic typing).

Obviously there is a request for variables that don't require a 
dedicated encoding (RAW) _and_ for variables that define their encoding 
by the name of their type.

So IMHO the Parent-Child (alike) relationship between RAW and any other 
new string type is quite obvious.

Thus I feel that it is a good idea that - wherever sensible - the 
behavior of the string types should be similar to that of object 
regarding the Parent-Child relationship. This is especially true with 
function parameters. (Recently there has been such a "fruitless" 
discussion on how the different string types should behave when used as 
formal/actual parameters)

With this definition (that should be easily understandable for those who 
are trained for working with object inheritance) you can use strict 
typing with clearly defined effects (conversion when different type 
names are combined), and (using RAW) you can take advantage of the 
dynamic encoding  (conversion "whenever necessary") with clearly defined 
effects as well.

The definition of what happens when RAW and it's "children" are combined 
also is quite obvious:

  - function parameters:
    - strict -> RAW: no conversion
    - RAW -> Strict: conversion whenever necessary

  - "combining" (compare, concat) raw and strict: conversion whenever 
necessary

There still are ambiguous cases:
  - "intersexual" variables (strict Typed variable that happens to be 
correctly done but with an encoding that does not match the type name)
  - RAW variables that in fact have a dynamic encoding definition of 
"NONE/RAW" and are to be converted into a strictly typed variable.
Handling this might be considered an "implementation detail". So Delphi 
compatibility is not necessary.


A result of this definition is that doing e.g.
RAWs1 := STRICTs2;
is independent of the actual current dynamic encoding of the target.

This might or might not be compatible to what Delphi XE does. But IMHO 
this is what might be considered as "obvious", So IMHO Delphi 
compatibility is not necessary.

> 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,
While I do think that the definitions I did in my first post were clear 
and self contained (but maybe I failed), I don't think it's viable to do 
a further elaboration on A) and B), as I feel that there is no real 
chance that something like this can make it into an official release 
(see above).

Regarding the (more complex) variant C), I hope I succeeded on making 
myself more clear with the text above. Again I tried not to suggest an 
_implementation_ but an approach to a _definition_ that finally should 
be clear, self-contained and easily acceptable and memorizeable for 
users of an object-language. (Just notice that the currently available 
implementation seemingly largely does what this definition requests.)

-Michael