RE: Re: LONGCHAR proposal

[Tim.Teulings@materna.de]

Hallo!

>I think this would be a useful addition to OOC. Currently, there is no good
>mapping for Unicode data types under Microsoft Windows. LONGCHAR would
>solve this problem.

I also think, this would be nice to have. I could also add a VOUniText
Module to VO, implementing use of Unicode in VisualOberon. X11 does
support Unicode in some way, too, however one has to do a lot of search
to get free Unicode fonts (nevertheless there is a FAQ or HOWTO for
that somewhere).

>characters (eg. control characters, Unicode characters). It would be useful

We would make the language again less interoperable with other
existing compilers. Whiele I think concatination is nice, it is not
part of the Oberon language.

>        ORD(x)     LONGCHAR            INTEGER      ordinal value of x
>        LONGCHR(x) integer type        LONGCHAR     long character with
>ordinal
>                                                    value x

Of course.

>I don't think the underlying run-time system will allow LONGCHARs in file
>names. This means that longstrings will need to be converted to strings,


AFAIK, NT stores all filename in Unicode under NTFS. However under
most systems (Linux, too) you have to convert the filename to 
a regular character string using some encoding system.

>I think approach (1) is probably the simpler and would be easier to
>maintain since it would not require dupication of the majority of the code.
>We could regard the "character width" as simply an attribute of the text.
>Thus, there would be only one TextRider class, but it would deal with
>either 1-byte and 2-byte characters. Character types should be able to be
>used interchangably, provided that they are representable. 

Isn't a file stored as Unicode or as normal text and as such isn't the
scanning mode part of the TextChannel. You would not store normal and 
unicode letters in the same textfile. Btw., is there some autodetection
mechanism?

>Thus, to define the Text type, we add:

[Possible solution].

Perhaps then we should make two reader/writer classes, since in your 
example nearly all methods have to be changed and have to check the type 
flag.

>It ought to be possible to make a clever TextRider.reader that
>automatically detects the width of the text stream, since 0 is not a valid
>text character but will start the majority of plain-text characters when
>represented in Unicode.

-- 
Gruß...
       Tim Teulings.
IDENTIFIKATIONSANGABEN:
a18475a.txt IA5 DX-MAIL X.400 User Agent