Re: Why no Ada.Wide_Directories?

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 21 Oct 2011 20:34:55 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>>> Not really. Wide_Wide_String is one possible implementation of logical
>>> Unicode string.
>> And precisely, that implementation is sufficient (*).
>
> Nope. Under Windows I rather need UTF-16 and ASCII. Under Linux it would  
> be
> UTF-8 and RADIX-50 for RSX-11.
This is implementation. The model on either an UTF-8 or an UTF-16 system,  
would still be the one of Wide_Wide_Character. Linux may be UTF-8  
internally, I use Unicode in Linux, not UTF-8. Windows may be UTF-16  
internally, I use Unicode in Windows and not UTF-16. From within neither,  
one will access UTF-8 or UTF-16 low level storage units, and instread will  
access Unicode character at hight level. If a given compiler implements  
Wide_Wide_Character using one or another encoding, is another story.

The error of using String in some areas of the standard packages, does not  
invalidate Wide_Wide_String.

>> You can't expect Ada
>> will provide a so much abstract implementation that it will cover all
>> possible implementations.
>
> Why not? Why should not a language provide abstractions for  character
> encoding?
A language is not a library, it provides most importantly, elementary  
semantic with which you design more complex things, more or less  
optionally built-ins models (which you can drop if you wish) for most  
important things or things identified as such (which is a subjective  
topic, you can just expect an average opinion), not for everything in the  
world. Providing a model for Unicode is reasonably enough.

>> (*) And that implementation is a clean view, unlike the one of String
>> holding UTF-8 data.
>
> You are confusing interface and implementation. This is one of Ada's
> problems that they are not clearly separated. Ada 83 pioneered the idea  
> of
> such separation for user-defined private types, but was not consequent to
> support it for other types, especially, for arrays and records.
Array and records are typically not to be publicly exposed. Most of time,  
when you define a record type, the record view appears in the package  
private part only, the same with arrays. The Ada standard library doesn't  
expose records (or else I can't recall one), but indeed exposes some  
arrays, which should be hidden in a clean design. However, this may be  
justified as a naive while still valid implementation, as much as a simple  
and efficient enough implementation. Arrays has an interface, even if this  
cannot be tweaked from the programmer's point of view. Array and records  
are basic bricks to implement types, not the core of the type models. This  
does not disallow pure abstract data types.


There are non-perfect things in the library, but as long as Ada as a  
language allows to define what you need, opinions should be measured.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit