Re: fyi, very interesting Ada paper OOP vs. Readability

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

"BrianG" <me@null.email> wrote in message news:jq68qj$de5$1@dont-email.me...
> On 05/30/2012 03:29 AM, Niklas Holsti wrote:
>> On 12-05-30 04:09 , BrianG wrote:
>>> On 05/11/2012 08:37 PM, Randy Brukardt wrote:
>>>> Ada should have had a "conversion" operator ("#" has been proposed), 
>>>> and
>>>> clearly Ada.Strings.Unbounded should use it. But that gets shot down 
>>>> every
>>>> time it is proposed (and it has been proposed for every language 
>>>> revision
>>>> other than Ada 2012); mainly because a minority think that "+" is 
>>>> perfectly
>>>> good for that. And another minority think that uses "+" on non-numeric 
>>>> types
>>>> is *disgusting*, so we can never get the operators added to packages. A
>>>> perfect impasse.
>>>>
>>> Why not unary "&", isn't that closer to the existing syntax?
>>>
>> Please, not "&", that would make calls look too much like calls in C
>> with pointer parameters. "&" being the C "address-of" operator. "&" is
>> also a large glyph, as tall as upper-case letters, making a following
>> identifier harder to recognize at a glance. How about "~"? Meaning, I
>> want "approximately" this value, but converted as necessary.
>>
> So I guess we should ban 'C' as a variable name too.  Who cares what looks 
> like C?  Does that somehow bring along with it the problems in C? How?
>
> We already have A := "This" & " That", Why not also B := &"The other", 
> that makes it perfectly analogous with D := 1 + 2 and E := +3.  (Yes, I 
> skipped C :-)  Function "&" already has an established meaning in Ada, why 
> not use it for a (somewhat) similar purpose?

That makes sense if you are *only* interested in conversions of strings. "&" 
makes no more sense for numbers than "+" makes sense for strings. The intent 
of the proposed "#" operator is that it be for the conversion of any type to 
any other type.

For instance, I could imagine using "#" to describe conversions of array of 
Element to vector of Element. Neither "+" nor your proposed "&" makes sense 
for that. The basic idea is that "#" would provide the effect of a 
user-defined type conversion.

An alternative idea that I've occassionally thought about has been to 
directly allow user-defined (value) type conversions. That is, provide a 
mechanism to allow the existing type conversion syntax to call a function in 
cases where there isn't already a defined conversion. This would work 
something like user-defined indexing does.

Then,

    Var := Unbounded_String("abc");

would be possible. (But note that this could end up nearly as wordy as the 
existing mechanism.)

                                          Randy.