Re: Why no Ada.Wide_Directories?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 20 Oct 2011 19:40:40 +0200, J-P. Rosen wrote:

> Le 20/10/2011 09:37, Dmitry A. Kazakov a �crit :
>> On Wed, 19 Oct 2011 16:43:08 -0500, Randy Brukardt wrote:
>> 
>>> > The only way to safely use a UTF-8 string is opaquely, which means you can 
>>> > store it whole, but any operation on it is performed after decoding it. 
>>> > That's of course the best argument for having it be a separate type.
>> Yes. It is worth to remember that Ada once was considered a strongly typed
>> language...
>> 
> Different types represent things that are of different nature.

Depends on the meaning "different":

1. Differently implemented types representing same entities from the
problem domain;

2. Incompatible types representing semantically different entities.

> It is not
> obvious that a difference in /encoding/ is sufficient to say that two
> things are of different nature.

#1 if encoding is not the problem domain, but an implementation detail,
which should be the case for most application programming;

#2 otherwise, e.g. in systems programming.

> Consider also the problem with files. Is a UTF-8 file a text file? Do
> you want a UTF8_IO package?

Not likely. For text files I would prefer single Text_IO package
consistently applying an appropriate recoding from the file encoding to the
representation of the string type used in the operation. Of course, the
targets, which do not support identification of the file encoding, will use
the Form parameter to specify it explicitly.

> A possible alternative solution could be to make UTF_8_String a type
> derived from String (rather than a subtype). With conversions allowed,
> you would not lose Text_IO. I don't know if we'll have time to discuss
> this in Denver, but if you are serious about it, by all means get in
> touch with your standardization body and let them make a comment. There
> is no point in saying "that's how it should have been", and taking no
> action to that effect.

Yes, String types must be kept different in the sense #1 and same in the
sense #2. That means that the type system should support classes (e.g.
Wide_Wide_String'Class) comprising types of *different* implementation,
which don't inherit representations from each other. This is not an issue
of strings. It is a general problem, which must be approached generally. So
far Ada has classes of shared representations for which upcasting and
downcasting are view conversions. Classes of different representation
should have physical conversions for T<->T'Class, T->S etc, creating new
objects. Yes, it is inefficient, but when efficiency is an issue the type
specific operations could always be overridden rather that inherited
through conversion.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de