Re: Your wish list for Ada 202X

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
...
> This is even more perplexing. It is two different statements:
>
> 1. I can invent a string type for all purposes, thus all applications will
> use it.

Certainly not.

> 2. Any given application needs only one string type, but different
> applications may require different string types.

This is, in general, true. There probably are some wild outlier cases where 
this is not true, but it should be very rare. It's certainly the rule I've 
used in my programs. The problem is that Unbounded_String (in it's existing 
Ada implementation) cannot truly be used in place of String.

> Both statements are evidently false.

Sure, if you literally mean *all* programs. But I've never meant that.

>> As a correllary, as many operations as possible should work with all
>> possible string types (Root_String'Class in my formulation) -- most of 
>> the
>> time when you need to use multiple string types, its because you have
>> libraries that only work with one type (String, Unbounded_String, 
>> whatever)
>> and you need to use some other type.
>
> Libraries and applications use different types because each type has
> certain advantages and disadvantages over any other type. This is why many
> string types are needed, deploying different memory management strategies,
> different encodings and different subsets of Unicode.

Right, and each application should use one such type. As far as libraries 
go, there's clearly two kinds. The only one I care about in this context are 
trying to provide some sort of general usage of strings. Restrictions on the 
type of strings that they operate on just get in the way.

>> So you end up converting back and
>> forth. If most the libraries simply take Root_String'Class, that doesn't
>> happen.
>
> It is as unrealistic as throwing out all numeric types and using arbitrary
> precision arithmetic instead. It simply does not work for real-life
> applications.

Huh? It's exactly how I would define Root_Integer'Class if we had such a 
thing. But the operations would be implemented using dispatching, no 
arbitrary precision arithmetic.

>> Ambiguous? That's the idea -- most consumers of strings don't care 
>> anything
>> about the properties of the string, just the sequence of code points that 
>> it
>> represents.
>
> Class-wide operations are overloaded, which is why.

Overloaded with what? The whole idea with class-wide operations is that 
there is only one of each. Only one body to maintain, works for everything.

>.. here". Such things are just plain bad, and surely aren't
>> going to happen here as nothing of the implementation is going to be
>> exposed. (I.e. either use Root_String'Class, or use a specific type - and
>> under no circumstances should you change mid-stream.)
>
> When the result is class-wide you have to cast it to the specific type. 
> You
> cannot go all the way with class-wide objects. It does not work.

Wow, proof by repeated assertion. It does indeed work, especially using 
containers holding class-wide items. You only go to specific types via 
dispatching, and one does that fairly rarely.

It's more of a problem with a object with a heavy, large interface, because 
one ends up missing operations. (Everything is impractical with a large 
interface - OO makes little sense for such types.) But that doesn't occur 
for simple things like string or integer, because the interface is small and 
complete.

---

It's becoming clear that there is no more to be learned here. We have no 
agreement even on the problem here, so there is no point about worrying 
about solutions. You are simply denying that the interesting problem can be 
solved at all, so there is no further point in talking to you on this topic.

                                         Randy.