renaming Interfaces.Java.Ada_To_Java_String to the + operator

renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Terry J. Westley]

Does anyone know who's idea it was to rename the
Interfaces.Java.Ada_To_Java_String function to the "+"
operator in the Intermetrics Java bindings?  I'm
using the Aonix ObjectAda translator but assume that
the Java class library came from Intermetrics.

Thanks much for this clever little idea.  IMHO, it
really improves ease of use and code readability. 

Does this idea originate with the Java work at
Intermetrics or does it predate it?

I find the inverse of + useful as well:

   function "-" (s : String_Ptr) return String
      renames Interfaces.Java.Java_To_Ada_String;

Does anyone think this is a misuse of operator
overloading?

-- 
Terry J. Westley, Principal Engineer
Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225
westley@calspan.com   http://www.calspan.com/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Terry asks

<<Does anyone know who's idea it was to rename the
Interfaces.Java.Ada_To_Java_String function to the "+"
operator in the Intermetrics Java bindings?  I'm
using the Aonix ObjectAda translator but assume that
the Java class library came from Intermetrics.
>>

This is an old, old idea (the use of unary + as a reasonably un-noisy
conversion operator). Jean Ichbiah was always a fan of this idea, which
I think was firmly in mind at the time of the original Ada design.

During the Ada95 revision, Jean suggested (and I supported) the idea
of a new unary operator (the currency conversion character, a small
square with inward curved sides is a nice choice) that would be undefined,
but available for user definition, with the specific idea that it be
used for this kind of conversion operator. However, the idea did not
catch many other people's imagination so it died.

Terry suggests using the "-" for the conversion in the other direction,
but I think that is a mistake. The use of "+" is reasonable because this
is a seldom used operator, since it has sort of "null" semantics, which
in a sense is just right for conversion. The negation operator has much
stronger semantics in typical use.

Also in a typical situation there is no real reason to think of conversion
in one direction being in any way non-symmetrical with conversion in the
other direction. The normal technique (for those who like the unary plus
technique, be aware that there are some people who *really* dislike this
usage) is to simply use "+" for both directions. The overloading resolution
figures out which one you are talking about.

Robert Dewar

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Matthew Heaney]

In article <dewar.884489205@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>Also in a typical situation there is no real reason to think of conversion
>in one direction being in any way non-symmetrical with conversion in the
>other direction. The normal technique (for those who like the unary plus
>technique, be aware that there are some people who *really* dislike this
>usage) is to simply use "+" for both directions. The overloading resolution
>figures out which one you are talking about.

I like this use of "+" as a conversion operation too.  I often use it
bounded strings:

subtype VString_Length_Range is Natural range 0 .. 80;

type VSTring (Length : VSTring_Length_Range := 0) is
   record
      S : String (1 .. Length);
   end record;

function "+" (S : String) return VString is
begin
   return VString'(S'Length, S);
end;

function "+" (VS : String) return String is
begin
   return VS.S;
end;


This way you can simulate something close to what you can do in C:

declare
   Table : constant VString_Array := 
     (+"this is a first element",
       +"second",
       +"yet another",
        +"this is the very last string I promise");
begin
...

If you meet someone who dislikes this use of "+", then tell them how it's
refered to in the RM: as the "identity" operator.  It has just the sort of
benign semantics Robert was refering to, which makes it ideal for this kind
of thing.  It's a more or less definitionless operator that the programmer
can define herself, to have the semantics she wants.  Perhaps the RM should
have made this more clear.

I think I read somewhere how Stroustrup thought that the identity operator
was basically useless, as it has no useful semantics.  That may be true in
C++, because the programmer can define conversion operators that get
invoked automatically.  But in Ada, what you see is what you get (except
for Controlled types), and so some constructor has to be called explicitly. 
The identity operator has just the syntactic lightness we're looking for
here.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Tom Moran]

What does
+"abc"&"xyz"
mean, and, more importantly, how many people know without having to
look it up?

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Tom Moran said

<<What does
+"abc"&"xyz"
mean, and, more importantly, how many people know without having to
look it up?
>>

Presumably in the
context you intend the "+" to be a unary conversion operator. This
conversion operator would then apply to "abc", since & is an adding
operator. Now I would not expect everyone to know the relative
precedence of these operators (I am too close to the compiler in
this regard, I even know what the value of -5/3 is, careful that's
a trick question :-)

So if you had to write this, I would think a responsible programmer
would write:

(+"abc") & "xyz"

to emphasize the meaning, although perhaps one might decide that the
normal spacing around binary operators is enough (such spacing is
a standard part of the GNAT lexical conventions, spaces for binary
operators, but not for unary operators)

 +"abc" & "xyz"

However, in real practice this is a somewhat unlikely piece of program
code in any case. Why? Because normally one would create a set of
coherent abstractions in which there was an & operator that did the
conversion automatically.

It is only when a term appears on its own that the use of "+" is
really necessary.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Stephen Leake]

Tom Moran wrote:
> 
> What does
> +"abc"&"xyz"
> mean, and, more importantly, how many people know without having to
> look it up?

A) concatenate "abc" and "xyz", getting "abczyz". Then convert to some
other string type.

B) me for one :)

Note that if "+" is defined to take String, it should also be defined to
take Wide_String. (Does Java support Unicode?)

-- 
- Stephe

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Stephen Leake]

Tom Moran wrote:
> 
> What does
> +"abc"&"xyz"
> mean, and, more importantly, how many people know without having to
> look it up?

Oops, I forgot to think about operator precedence in my first post (I
see now that is the point of Tom's post :(.

This means:

convert "abc" to some other type, then concatenate "xyz"

The responsible package author will overload "&" as well as "+", to
handle this correctly, as the reader's first impulse expects :).

-- 
- Stephe

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Nick Roberts]

No he won't Stephe.  Operator precedence is fixed in Ada.  This is (cited
as) one of Ada's design features.  +"abc"&"xyz" means "+"("abc")&"xyz"
always.  (You need to modify your impulses ;-)
-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote in article
<34BBBB88.DDE@gsfc.nasa.gov>...
> Tom Moran wrote:
> > 
> > What does
> > +"abc"&"xyz"
> > mean, and, more importantly, how many people know without having to
> > look it up?
> 
> Oops, I forgot to think about operator precedence in my first post (I
> see now that is the point of Tom's post :(.
> 
> This means:
> 
> convert "abc" to some other type, then concatenate "xyz"
> 
> The responsible package author will overload "&" as well as "+", to
> handle this correctly, as the reader's first impulse expects :).
> 
> -- 
> - Stephe
> 

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

<<is syntactically illegal, without looking it up (and without feeding it
to a compiler)?  GNAT complains "missing operand" pointing to the second
plus, which isn't the most helpful error message I've ever seen.
Rational's compiler complains about a missing expression before the
second plus, which is no better.
>>

[This was for the illegal use of unary plus and minus as in

   x & + b

it is always hard to know what might be the "most helpful" message, since
of course this involves telephathy. I wonder if we changed this to
"unary plus[minus] requires parenthesization in this context"

or somesuch, would this be an overall improvement, maybe, it is a tossup.
The problem is that one or the other is correct but it is hard to tell
which.

Yes, if you got fancy you could use type information to tell, but that's
reallyu *awfully* heavy in implementation complexity.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Stephen Leake]

Robert Dewar wrote:
> 
> <<is syntactically illegal, without looking it up (and without feeding it
> to a compiler)?  GNAT complains "missing operand" pointing to the second
> plus, which isn't the most helpful error message I've ever seen.
> Rational's compiler complains about a missing expression before the
> second plus, which is no better.
> >>
> 
> [This was for the illegal use of unary plus and minus as in
> 
>    x & + b
> 
> it is always hard to know what might be the "most helpful" message, since
> of course this involves telephathy. I wonder if we changed this to
> "unary plus[minus] requires parenthesization in this context"
> 
> or somesuch, would this be an overall improvement, maybe, it is a tossup.
> The problem is that one or the other is correct but it is hard to tell
> which.

Perhaps you can just print both error messages; let the user figure it
out. When there are only two choices, this isn't bad. In places where
there are lots of choices, maybe you could have a "verbose error"
compiler option.

> 
> Yes, if you got fancy you could use type information to tell, but that's
> reallyu *awfully* heavy in implementation complexity.

-- 
- Stephe

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

I asked:

<<is syntactically illegal, without looking it up (and without feeding it
to a compiler)?  GNAT complains "missing operand" pointing to the second
plus, which isn't the most helpful error message I've ever seen.
Rational's compiler complains about a missing expression before the
second plus, which is no better.
>>

[This was for the illegal use of unary plus and minus as in

   x & + b

it is always hard to know what might be the "most helpful" message, since
of course this involves telephathy. I wonder if we changed this to
"unary plus[minus] requires parenthesization in this context"

or somesuch, would this be an overall improvement, maybe, it is a tossup.
The problem is that one or the other is correct but it is hard to tell
which.
>>



But was disappointed to get almost no response (Stephe thanks!) The one
response suggests giving both messages, but I think it is better generally
to choose just one. The trouble with giving two is that then you are
absolutely SURE you have generated at least one junk message, which seems
unforutnate.

But I really would like some more input on this (surely we still have
*some* Ada folks around the newsgroup, and not just cross-posting
trollers :-)

It is really useful to have lots of input on error message things, since
they are so subjective.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Anonymous]

<01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>
<dewar.884489205@merv> <mheaney-ya023680001001982248520001@news.ni.net>
<34bba5a1.224459@SantaClara01.news.InterNex.Net>
<En3Cxz.7HD@world.std.com> <dewar.885328875@merv>

On 22 Jan 1998 01:18:36 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>
> 
>    x & + b

asking for comments about the error message that a compiler should put
out when it encounters this kind of construct. The writer intended to
use unary "+", but forgot to surround "+b" with parentheses.

I frequently don't see postings to this newsgroup, or see them out of
order. This is the first I've seen of Dewar's request about this. If I'd
seen it earlier, I might have replied earlier.

"X & + B" might be "X & Y + B", where the writer didn't hit the Y key
hard enough and didn't notice it, or it might be "X & (+ B)" without
parentheses. If it's the former, the compiler should put out an error
message about missing the left operand for binary "+"; if the latter,
about needing parentheses for unary "+" in this context. Is it possible
for the compiler to tell the difference?

In real Ada, we're more likely to see "Xenia & +Bernard" than "X & + B"
(spaces significant). It this likely to be a typo for "Xenia & Yakob +
Bernard"? I think not. Therefore, I think the error message should
generally be about unary "+".

Also, unary "+" and "-" generally don't have following spaces (though
I've seen pretty-printed code where they did), so the spacing could give
a clue as to what was intended.

That's my valeur de deux centimes.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Tom Moran]

>How universal is the convention of no space after unary operators?
In scanning the 60 or so software components on the Walnut Creek CDROM
I found 26 uses of unary "+", none followed by a space.
(TARTE has 14, all in machine code calls and MATPACK has 12, all but
one in Assert calls
  Perhaps it would be more useful, though, to scan some programs using
the Intermetrics Ada -> Java binding.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Geert Bosch]

Robert Dewar wrote:

   How universal is the convention of no space after unary operators?

Depends on the operator of course ;-). Operators like "not" and "abs"
will be followed by a space usually, but a space after a unary "+" or "-"
would be very confusing (at least to me). Code like
   A := + 3;
makes me think an A was forgotten after the ":=". 

I'd think for error recovery purposes it is safe to assume that
unary plus/minus is not followed by a space. So plus/minus followed
by space is binary and "missing operand" is correct diagnosis,
otherwise operator may be unary or binary and the longer message
should be given.

Regards, Geert

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Anonymous]

<199801221427.PAA05971@basement.replay.com>

On 22 Jan 1998 15:00:06 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> 
> How universal is the convention of no space after unary operators?
> 
> GNAT quite often uses spacing as a clue for messages. FOr example
> 
>    a := b
>    c;
> 
> generates a missing semicolon flagged right after the b, but
> 
>    a := b c;
> 
> generates a missing operator message flagged between the b and the c.
> 
> So this is a definite possible way of making the distinction if it seems
> statistically right to do so.
> 
> Of course the double barrelled error message
> 
>   missing operand or missing parentheses around unary "+"
> 
> is not too long, so that's a possibility with two votes so far ...
> 

Yeah, that one's OK.

I've never seen hand-written code with a space after unary "+" or "-".
(Hand-written code always has a space after "abs", which is a unary
operator. Henceforth, I'm only talking about unary "+" and "-".)
However, I have seen code formatters that put a space between them and
the operand (Rational Apex is one, if I'm not mistaken).

As for statistics about spacing and unary operators, what are the
statistics from your several MSLOC regression test suite + ACVC + DEC
tests? That's probably as representative a sample as anyone has access
to.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

: ...
: But I really would like some more input on this (surely we still have
: *some* Ada folks around the newsgroup, and not just cross-posting
: trollers :-)

: It is really useful to have lots of input on error message things, since
: they are so subjective.

For what it is worth, this is what our AdaMagic front end produces
for an illegal <binary op> <unary op> sequence:

Source file: unary_plus.ada.bad   Sat Jan 24 11:05:19 1998

    1 procedure unary_plus is
    2     x : Integer;
    3 begin
    4     x := x - + x;
                   *   
*****Error: LRM:4.5(8) Badly formed expression; possibly missing '(', skipping
*****        to next separator
    5 end;

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Chris Morgan]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 
> Terry asks
> 
> <<Does anyone know who's idea it was to rename the
> Interfaces.Java.Ada_To_Java_String function to the "+"
> operator in the Intermetrics Java bindings?  I'm
> using the Aonix ObjectAda translator but assume that
> the Java class library came from Intermetrics.
> >>
> 
> This is an old, old idea (the use of unary + as a reasonably un-noisy
> conversion operator). Jean Ichbiah was always a fan of this idea, which
> I think was firmly in mind at the time of the original Ada design.
> 

In the Intermetrics X11 and Motif bindings there is a generic &
operator which is used to approximate the variable argument list C
functions in the original interface, allowing you to write stuff like
this :

    Button1 := Xt.Intrinsic.XtVaCreateManagedWidget(
	"redraw", Motif.Pushb.xmPushButtonWidgetClass_obj, Form , 
	Stdarg.Empty & Motif.xmstrdefs.XmNlabelString & label & 
		       Motif.Xmstrdefs.Xmntopattachment & 
		       Motif.Xm.Xmattach_Form &
		       Motif.Xmstrdefs.Xmntopoffset & 2 &
		       Motif.Xmstrdefs.Xmnleftattachment & 
		       Motif.Xm.Xmattach_Form & 
		       Motif.Xmstrdefs.Xmnleftoffset & 2 &
						    Nulst);


Whilst I'm not complaining this is elegant it reads close enough to
the C that it's reasonably comprehensible to experience C/Motif
programmers. Once I got the hang of it was fine. I thought Mitch did a
good job with this.

Chris

-- 
Chris Morgan <mihalis at ix.netcom.com>
     "I'm considering throwing myself out of the window.  It
      wouldn't do me much damage because we're on the ground 
      floor, but it might make for a bit of variety."  - Lizzy Bryant

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Chris said

<<In the Intermetrics X11 and Motif bindings there is a generic &
operator which is used to approximate the variable argument list C
functions in the original interface, allowing you to write stuff like
this :
>>

The other way of handling variable length lists is to use an
aggregate

   subprogname ((arg1, arg2, arg3, arg4, ....));

that is definitely neater than &. Furthermore, if you use the & approach
you have to be very careful not to introduce quadratic processing (which
is often quite tricky to do, if the target is really an array (*))

If you need heterogenous typing, then you define an appropriate union
type, and convert to it:

   subprogname ((+arg1, +arg2, +arg3, +arg4, ....))

which still retains linear processing time. If Chris' example is anywhere
near realistic (where many operands were joined with &), then I think the
use of & was probably not such a good choice as using aggregates.

(*) the problem of aggregated operators, concatenation on strings is
a canonical example, is an interesting one. No language in common use
tries to address the issue of converting

      A & B & C & D ...

into what is wanted, which is

      Concat ((A,B,C,D ...))

I can certainly imagine a pragma that would have this effect:

      pragma Collect_Operation (Operation => name, Subprogram => name);

where the parameters designate the dyadic operator to be treated,
which needs to have the profile (typ X typ => typ), and the
corresponding subprogram, which needs to have the profile
(row-of-typ => typ).

To use this for the builtin concatenation (many compilers special case this,
we just added this kind of special casing to GNAT), you also need to deal
with rowing of elements, i.e. if the operand typ is itself row-of-component,
then you allow components in the list with automatic rowing operations.


P.S. the above uses ALgol-68 notation and terminology, which is highly
convenient in a case like this:

row-of-x is a type that is a single dimension array whose component
type is x

rowing is the coercion that takes type x to type row-of-x

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Chris Morgan]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> which still retains linear processing time. If Chris' example is anywhere
> near realistic (where many operands were joined with &), then I think the
> use of & was probably not such a good choice as using aggregates.
> 

Your concern being compilation time and efficiency whereas I was
thinking of my ability to transfer my C/Motif skills over to the Ada
lobe of my brain :-)

Certainly my example was from real code, but as it was my code I can't
say if it was realistic for others.

Was there a review of the bindings or where they just commisioned and
produced?

One interesting feature of them is that almost none of the examples of
X and Motif programming given in the literature work with a simple
translation of C to Ada since the type safety of Ada is so much
stronger (the C examples relying on unportable assumptions and silent
coercions).

Chris

-- 
Chris Morgan <mihalis at ix.netcom.com>
     "I'm considering throwing myself out of the window.  It
      wouldn't do me much damage because we're on the ground 
      floor, but it might make for a bit of variety."  - Lizzy Bryant

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Chris said

<<Your concern being compilation time and efficiency whereas I was
thinking of my ability to transfer my C/Motif skills over to the Ada
lobe of my brain :-)
>>

That's a very legitimate concern and indeed is one of the major arguments
in favor of thin bindings. However, it is still reasonable to worry
about execution time efficiency! (I don't understand your comment about
compilation time here, I don't see that as an issue at all).

From my point of view

   (a,b,c,d,e,f,g)

is as reasonable translation of

   a,b,c,d,e,f,g

as

   a & b & c & d & e & f & g

actually, I think it is MORE reasonable. Now of course we can have & take
care of the conversions if they are needed automatically, in which case
the fair comparison is with

   (+a,+c,+c,+d,+e,+f,+g)

but still that's fairly reasonable, and I don't think any of these
conventions will intefere with inter-lobel transfer of knowledge.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Chris Morgan]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> That's a very legitimate concern and indeed is one of the major arguments
> in favor of thin bindings. However, it is still reasonable to worry
> about execution time efficiency! (I don't understand your comment about
> compilation time here, I don't see that as an issue at all).

For some reason your mention of quadratic time made me think of
parsing the line of code I gave (no idea what order parsing actually
would be) but I did mention efficiency as well by which I meant the
run-time behaviour - I am aware for instance that 

text_io.put(a & b & c .... );

used to be very unpleasantly slow with at least one Ada83 compiler.

> 
> From my point of view
> 
>    (a,b,c,d,e,f,g)
> 
> is as reasonable translation of
> 
>    a,b,c,d,e,f,g
> 
> as
> 
>    a & b & c & d & e & f & g
> 
> actually, I think it is MORE reasonable. Now of course we can have & take
> care of the conversions if they are needed automatically, in which case
> the fair comparison is with
> 
>    (+a,+c,+c,+d,+e,+f,+g)
> 
> but still that's fairly reasonable, and I don't think any of these
> conventions will intefere with inter-lobel transfer of knowledge.


I think all those would be fine. I was just saying it was nice that
someone had offered something to allow an approximation of the varargs
C functions rather than the previous approach of saying "sorry, Ada
doesn't do varargs so you will have to use the non-varargs versions
instead" which wouldn't have fitted in with my accustomed style of
Motif programming.

Chris



-- 
Chris Morgan <mihalis at ix.netcom.com>
     "I'm considering throwing myself out of the window.  It
      wouldn't do me much damage because we're on the ground 
      floor, but it might make for a bit of variety."  - Lizzy Bryant

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Chris said

<<I think all those would be fine. I was just saying it was nice that
someone had offered something to allow an approximation of the varargs
C functions rather than the previous approach of saying "sorry, Ada
doesn't do varargs so you will have to use the non-varargs versions
instead" which wouldn't have fitted in with my accustomed style of
Motif programming.
>>

Well I am surprised that anyone would have taken this "previous" approach.
Certainly the possibility of using array aggregates in this way is the
reason that you don't need varargs type support in a language like Ada
(this is not a new idea, this usage is completely familiar from Algol-68).

So this is not some kind of "neat discovered trick" in the language, it is
an important part of the intended design!

Regarding the quadratic behavior, and your mention of efficiency in Ada 83,
in fact if you think about

   a & b & c & d

the natural implementation will definitely be quadratic, since this really
means

  ((a & b) & c) & d)

and in the general case, e.g. with user defined concatenation, must be
done in three separate operations. A compiler can specially recognize
this case, but it is not a trivial optimization (I just put it into GNAT,
and it took a full day of work to get it right).

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Nick Roberts]

I dislike this usage, in commercial programming situations, usually. The
reason is well known: that it can often be confusing (or, at least, less
obvious) for programmers new to the library environment or project. I think
it's fair to say, also, that this sort of notation can be so 'quiet' as to
be overlooked, and thus a source of mistakes (which would have been avoided
with a 'louder' notation).

Given that the only reason (tell me if I'm wrong) is to abbreviate an
identifier, essentially, I feel it is rarely justifiable. If the programmer
feels that an identifier is too long ("Ada_To_Java_String" perhaps), it can
always be renamed (or subtyped or whatever) to a shorter, but still
meaningful, identifier ("A2Jstr" possibly).

One of the real practical strengths of Ada is its lack of obscure notation.
I'm a real fan (as you can tell :-) of this clarity.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Terry J. Westley <westley@calspan.com> wrote in article
<01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>...
> Does anyone know who's idea it was to rename the
> Interfaces.Java.Ada_To_Java_String function to the "+"
> operator in the Intermetrics Java bindings?  I'm
> using the Aonix ObjectAda translator but assume that
> the Java class library came from Intermetrics.
> 
> Thanks much for this clever little idea.  IMHO, it
> really improves ease of use and code readability. 
> 
> Does this idea originate with the Java work at
> Intermetrics or does it predate it?
> 
> I find the inverse of + useful as well:
> 
>    function "-" (s : String_Ptr) return String
>       renames Interfaces.Java.Java_To_Ada_String;
> 
> Does anyone think this is a misuse of operator
> overloading?
> 
> -- 
> Terry J. Westley, Principal Engineer
> Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225
> westley@calspan.com   http://www.calspan.com/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Brian Rogoff]

On 11 Jan 1998, Nick Roberts wrote:

> I dislike this usage, in commercial programming situations, usually. The
> reason is well known: that it can often be confusing (or, at least, less
> obvious) for programmers new to the library environment or project. I think
> it's fair to say, also, that this sort of notation can be so 'quiet' as to
> be overlooked, and thus a source of mistakes (which would have been avoided
> with a 'louder' notation).

Would your discomfort be less if Ada allowed user defined unary and infix 
operators, so that some new notation could be invented? Or is it the use
of *any* unary operator rather than a named conversion function
distasteful? Personally, I rather like the "+" as a converter notation; I 
saw it early in my Ada education and thought it was a fairly standard
idiom. As was pointed out elsewhere it can be used bidirectionally because 
of Ada's overloading. 

> Given that the only reason (tell me if I'm wrong) is to abbreviate an
> identifier, essentially, I feel it is rarely justifiable. 

Why? I thought the goal was readability. Sometimes compact code is more
readable.

> One of the real practical strengths of Ada is its lack of obscure notation.
> I'm a real fan (as you can tell :-) of this clarity.

Well, when I was doing a lot of numerical linear algebra and signal
processing work, I really wished that I could invent my own unary and 
infix operators rather than being forced to use function call syntax 
for everything. While I'm sure that someone could use that to write really 
ugly code, there are situations where that notation (obscure to an
outsider) could have made code much nicer. 

-- Brian

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Terry J. Westley]

Brian Rogoff <bpr@shell5.ba.best.com> wrote in article 
> Well, when I was doing a lot of numerical linear algebra and signal
> processing work, I really wished that I could invent my own unary and 
> infix operators rather than being forced to use function call syntax 
> for everything. While I'm sure that someone could use that to write
really 
> ugly code, there are situations where that notation (obscure to an
> outsider) could have made code much nicer. 

This is precisely the sort of thing:

   A = B + C

which made FORTRAN so popular.  The programmer couldn't invent
his/her own operators of course, but it was a big improvement over:

   LD  B
   ADD C
   STO A

for readability.  In the same way, use of the + operator can
make a program more readable, not less.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Terry says

<<for readability.  In the same way, use of the + operator can
make a program more readable, not less.
>>

Absolutely! And the same can be said of absolutely all features in the
language

 use of xxx can make a program more readable, not less

But on the other hand it is also true that

 use of xxx can make a program less readable, not more

And both statements are true for all xxx.

I know people desparately want simple rules that somehow guarantee readability,
but the fact of the matter is that judgment is called for in most cases, and
having the skill to make the judgment correctly is one of the important
skills that programmers need to have or acquire.

Yes, sets of official guidelines and rules can help, but they are not a
susbtitute for good judgment!

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Nick Roberts]

Robert's comment [below] is surely a valuable one in a topic which
threatened to get too general.

I have to say, however, I would still assert that something like

   File_Name_1_In_Java := To_Java_String(File_Name_1);

is better than

   File_Name_1_In_Java := +File_Name_1;

in the vast majority of cases.  I hope this example is not felt to be
unfair by those who disagree with me.

My point is this: what is truly gained by the second version?

Unary + as a string translator is not a generally idiomatic form, although
I admit it could become one, and its use is far from obscure already.  I
still think that the first form should be encouraged in commercial and
industrial practice, simply because it is more explicit.  In how many cases
is the fact that it is a little longer going to really matter?

Even with a case such as

   File_Name_List := (To_Java_String(Comment_File_Name),
                      To_Java_String(Keyword_File_Name),
                      To_Java_String(Command_File_Name),
                      To_Java_String(Function_File_Name),
                      To_Java_String(Movename_File_Name),
                      To_Java_String(Oldname_File_Name),
                      To_Java_String(Dictionary_List_File_Name),
                      To_Java_String(Thesaurus_List_File_Name),
                      To_Java_String(Grammar_Rule_File_Name));

could this be considered so much less preferable to, say

   File_Name_List := (+Comment_File_Name,
                      +Keyword_File_Name,
                      +Command_File_Name,
                      +Function_File_Name,
                      +Movename_File_Name,
                      +Oldname_File_Name,
                      +Dictionary_List_File_Name,
                      +Thesaurus_List_File_Name,
                      +Grammar_Rule_File_Name);

where, again, I hope this example is felt to be fair.

I would suggest that the latter form, while a little 'cleaner', could still
be confusing to a reader who didn't already know that unary + had been
defined to convert strings, whereas such a reader would be likely to
correctly surmise what is going on from the first form.  I would assert
that this advantage tells over the advantage of slightly cleaner or shorter
code in almost all cases.  Am I missing the point?

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.884801478@merv>...
> I know people desparately want simple rules that somehow guarantee
readability,
> but the fact of the matter is that judgment is called for in most cases,
and
> having the skill to make the judgment correctly is one of the important
> skills that programmers need to have or acquire.
> 
> Yes, sets of official guidelines and rules can help, but they are not a
> susbtitute for good judgment!

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Nick says

<<I have to say, however, I would still assert that something like

   File_Name_1_In_Java := To_Java_String(File_Name_1);

is better than

   File_Name_1_In_Java := +File_Name_1;

in the vast majority of cases.  I hope this example is not felt to be
unfair by those who disagree with me.

My point is this: what is truly gained by the second version?
>>


Well anyone can assert anything!

The point is that we cannot tell from your example which is clearer. The
issue is whether it is important at the appropriate level of abstraction
to emphasize that there are two types involved here. If yes, then the
top line is preferable, if no, then the bottom line is preferable, since
the "To_Java_String" is irrelevant noise.

Note that when you say 

  A := B;

you are quite happy with this even though A and B have different subtypes.

Now if in fact A is of subtype Integer range 1 .. 10 and B is of subtype
Integer, and a major function of the assignment statement is the range
check, then it would not come amiss to say

  A := Restricted_Integer_Range_Type (B);

but normally this is NOT a major semantic component of what is going on
(even though the check might be there), and we are very happy to not be
forced to write the type name for this kind of subtype conversion check.

Now in the case where two separate types are involved, the conversion
between them may or may not be significant. I can easily imagine a
situation where you are using two packages, each of which instantiates
a copy of bounded string for 100 character strings. You are stuck with
these two types because that's the way the packages came, but as far
as you are concerned it would have been better if they had been the
same type, and the type conversions are entirely artifacts and have
zero semantic significance. In such a case the + is appropriate (and
in fact a bit too noisy, since implicit conversion would be fine in
this case, but + is not too bad as an approximation of nothing :-)

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Michael F Brenner]

(discussing using a prefix + operator to change types)

   > .. in what cases will the extra length really matter ..

Using a function call (say, about 10 characters long) versus
using a single character (+) to represent the type change
is more readable on a single instance of the conversion.

The place where the extra length really matters is when you
have a lot of input to do, say 10000 lines, then you are saving
100000 key strokes, which could be a lot of data input money.

This almost suggests a compromise that unary operators should
have a corresponding function name. Use the function name
for small numbers (say 10 or fewer) instances.

Use the prefix operator when doing large amounts of stuff, like
defining large finite state machines, filling in giant arrays,
making test cases, defining test scenarios for a package body, etc.

Mike Brenner

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Mike says

<<The place where the extra length really matters is when you
have a lot of input to do, say 10000 lines, then you are saving
100000 key strokes, which could be a lot of data input money.

This almost suggests a compromise that unary operators should
have a corresponding function name. Use the function name
for small numbers (say 10 or fewer) instances.

Use the prefix operator when doing large amounts of stuff, like
defining large finite state machines, filling in giant arrays,
making test cases, defining test scenarios for a package body, etc.
>>


I strongly disagree with the above. Which of the two forms is preferable
is a matter of semantic levels of discourse, and if one form is clearer
if used once it is clearer if used 1000 times.

The idea that one should take into account the effort of the writer is
entirely wrong-headed. In the Ada world, we always favor the reader over
the writer. So arguments should always be framed in terms of what will
be easier to read.

If you indeed think that in the case of a single instance, the long name
is always clearer, then I cannot see how this does not apply to the
multiple occurrence case. Of course I do not agree with this premise, for
reasons I have explained in detail previously.

P.S. I will tell you an amazing technique for saving those 100000 key
strokes. Type them in using +, and then use the amazing global replace
technology found in all editors for the last 30 years, and replace the
plus signs with what ever long name you want (well you will have to
fiddle with parens too, but this is also easy enough to automate :-)

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Nick Roberts]

Precisely right, Mikey babe,  You've more or less listed precisely those
rare cases that I was banging on about.  I know, I know, I know, you
yourself use lots and lots of FSTs; but I would suggest, in the great
scheme of things, that large FSTs, giant arrays, etc. constitute rare
cases.  (No? :-)

To use this spot to answer Robert Dewar also (ever conscious of bandwidth,
signal to noise ratios etc.), Robert argues that the use of explicit
conversions or not depends on the level of abstraction, which I
wholeheartedly agree with.  He then says that in cases where the level of
abstraction does not suit an explicit conversion, use of the unary +
operator approximates to an implicit conversion (which Ada does not support
generally).  Well, true, it's nearer than a great long identifier and
brackets; but it's still not an implicit conversion, and it's appearance
will (probably) worry a programmer who doesn't already know what it means,
whereas the explicit identifier (probably) won't.

What I'm saying is that it is actually slightly more pragmatic to use the
explicit identifier, except in those (rare!) cases such as large FSTs,
giant arrays, etc. where reducing bulk would actually matter (and, indeed,
improve readability).

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<69ntk6$qj8@top.mitre.org>...
> Using a function call (say, about 10 characters long) versus
> using a single character (+) to represent the type change
> is more readable on a single instance of the conversion.
> 
> The place where the extra length really matters is when you
> have a lot of input to do, say 10000 lines, then you are saving
> 100000 key strokes, which could be a lot of data input money.
> 
> This almost suggests a compromise that unary operators should
> have a corresponding function name. Use the function name
> for small numbers (say 10 or fewer) instances.
> 
> Use the prefix operator when doing large amounts of stuff, like
> defining large finite state machines, filling in giant arrays,
> making test cases, defining test scenarios for a package body, etc.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Nick Roberts says

<<To use this spot to answer Robert Dewar also (ever conscious of bandwidth,
signal to noise ratios etc.), Robert argues that the use of explicit
conversions or not depends on the level of abstraction, which I
wholeheartedly agree with.  He then says that in cases where the level of
abstraction does not suit an explicit conversion, use of the unary +
operator approximates to an implicit conversion (which Ada does not support
generally).  Well, true, it's nearer than a great long identifier and
brackets; but it's still not an implicit conversion, and it's appearance
will (probably) worry a programmer who doesn't already know what it means,
whereas the explicit identifier (probably) won't.
>>

Indeed the use of the "+" notation assumes that programmers are familiar
with this idiom. It is an old one which was well understood at the time of
the original design, and I would have thought it was pretty universally
known. Certainly it is something that all Ada programmers should be familiar
with. Even if you don't like to use it yourself, you are highly likely to
run into code that does use this convention.

I certainly agree that the use of idioms like this is often quite dependent
on familiarity. 

Of course in this particular case, it seems to me that a programmer
who was unfamiliar with this notation would quickly find out what was
going on. You encounter the operator +, and in the normal manner, seek
out its definition (using whatever special tools ytou have to help with
this). Then the spec of this "+" will of course have comments explaining
the use.

Anyway, it is clear that one benefit of this thread is that at least the
current readers of CLA are now familiar with this very standard idiom,
whether or not they choose to use it themselves :-)

Re: miniscences

[Nick Roberts]

I do a lot of training of Ada programmers (no more jokes about the blind
leading the blind, please :-}.  I shall have to add this one to the list
(it gets longer and longer :-|  You say this is an old idiom: how old? 
[Uncle Nicky nearly goes back to when the only things programmed were
programmed with pins in boards]  I remember the days when it wowed us when
we could put MID$ on the left.  And when Crystal (remember them?) had got
their BASIC into a 6K ROM.  [Here we go...]  I remember the days [pillow
hits head] who threw that?  Oooh yes, I was once the proud owner of the
original Sinclair computer (can't even remember what it was called now). 
You know, the one with 1K of RAM, of which three-quarters was needed for
displaying a screenful of info?  Ah, those were the days.  None your unary
operators then.  Those days it was lone operators.  Ever tried getting a
real BASIC program into 300-400 bytes?  Ah yes, you had to be a _man_ to
program those days.  Ah, yes [another pillow] who threw that?  [Etc...]

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.884996680@merv>...
> Indeed the use of the "+" notation assumes that programmers are familiar
> with this idiom. It is an old one which was well understood at the time
of
> the original design, and I would have thought it was pretty universally
> known. Certainly it is something that all Ada programmers should be
familiar
> with. Even if you don't like to use it yourself, you are highly likely to
> run into code that does use this convention.
> 
> I certainly agree that the use of idioms like this is often quite
dependent
> on familiarity. 
> 
> Of course in this particular case, it seems to me that a programmer
> who was unfamiliar with this notation would quickly find out what was
> going on. You encounter the operator +, and in the normal manner, seek
> out its definition (using whatever special tools ytou have to help with
> this). Then the spec of this "+" will of course have comments explaining
> the use.
> 
> Anyway, it is clear that one benefit of this thread is that at least the
> current readers of CLA are now familiar with this very standard idiom,
> whether or not they choose to use it themselves :-)

Re: miniscences

[Robert Dewar]

Nick asks

<<I do a lot of training of Ada programmers (no more jokes about the blind
leading the blind, please :-}.  I shall have to add this one to the list
(it gets longer and longer :-|  You say this is an old idiom: how old?
>>

As old as the Ada design. During the Green design effort (i.e. late 70's),
the issue of whether to have implicit conversions was discussed, and at
that time Jean felt, and others generally agreed, that the use of the "+"
operator in this way meant that you have the possibility of making the
conversion pretty close to silent from a reading point of view, and that
therefore it was not necessary to introduce implicit convresions.

After all, look at the number of people who find even the + too silent,
and would prefer to see a full identifier here. Imagine the situation
in a langyuage like C++ with implicit conversions where you can have
a lot going on behind the scenes with no syntactic hint at all.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Anonymous]

<01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>
<01bd1fc9$99302a00$24326489@Westley-PC.calspan.com>
<dewar.884801478@merv> <01bd21ff$7f85e3a0$95fc82c1@xhv46.dial.pipex.com>
<69ntk6$qj8@top.mitre.org>
<01bd22bd$0b69fa60$5cfd82c1@xhv46.dial.pipex.com>

On 16 Jan 1998 19:29:43 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> ...
>
> Indeed the use of the "+" notation assumes that programmers are familiar
> with this idiom. It is an old one which was well understood at the time of
> the original design, and I would have thought it was pretty universally
> known. Certainly it is something that all Ada programmers should be familiar
> with. Even if you don't like to use it yourself, you are highly likely to
> run into code that does use this convention.
> 

I've been developing software professionally since 1975, and using Ada
since 1984, and I only recently encountered this "old idiom" by reading
about it here. Perhaps it is familiar only to those involved in the
language design and implementation. I know I never encountered it in 14
years of reading the ARM, Ada texts, and Ada-related articles.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"English bed-wetting types."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Matthew Heaney]

In article <199801191436.PAA25860@basement.replay.com>, nobody@REPLAY.COM
(Anonymous) wrote:

>I've been developing software professionally since 1975, and using Ada
>since 1984, and I only recently encountered this "old idiom" by reading
>about it here. Perhaps it is familiar only to those involved in the
>language design and implementation. I know I never encountered it in 14
>years of reading the ARM, Ada texts, and Ada-related articles.

This technique was discussed in John Barnes' book, Programming In Ada.  He
used it to construct a ragged array of strings.  Actually, that turns out
to be a popular use of the identity operator, to populate an array:

declare
   Aardvark : aliased constant String := "aardvark";
   ...
   Elephant : aliased constant String := "elephant";
   ...
   Zebra : aliased constant String := "zebra";

   type String_Access_Constant is access constant String;

   type String_Array is
      array (Positive range <>) of String_Access_Constant;

   Animals : constant String_Array :=
     (Aardvark'Access,
      ...
      Elephant'Access,
      ...
      Zebra'Access);
begin

This is more or less the example in John's book.  (His Ada 83 example put
the strings on the heap, using the identity operator to hide to allocator
invokation.)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

Nick says

<<I dislike this usage, in commercial programming situations, usually. The
reason is well known: that it can often be confusing (or, at least, less
obvious) for programmers new to the library environment or project. I think
it's fair to say, also, that this sort of notation can be so 'quiet' as to
be overlooked, and thus a source of mistakes (which would have been avoided
with a 'louder' notation).

Given that the only reason (tell me if I'm wrong) is to abbreviate an
identifier, essentially, I feel it is rarely justifiable. If the programmer
feels that an identifier is too long ("Ada_To_Java_String" perhaps), it can
always be renamed (or subtyped or whatever) to a shorter, but still
meaningful, identifier ("A2Jstr" possibly).
>>

Everyone agrees with this general principle, but the fact of the matter is
that identifiers with associated parentheses can obfuscate code, and at
some level most people agree. Witness for example, the big fuss about
adding "use type", which is basically so that even people who are use-
allergic can still use nice infix notation for operators, as in

   x * b + c

instead of

   Pkg1."+" (Pkg1."*" (x, b), c)

hands up anyone who thinks the second line will prove clearer to the
maintenance programmers :-)

In fact many languages are happy to have *ZERO* syntactic overhead for
conversions (e.g. C++). I think the use of unary "+" for this purpose
is a quite reasonable compromise. Note that of course it should only
be used when conceptually there is very little abstract difference
between the input and output, as for example the case of a character
treated as a one character string, or an integer treated as a real.

If we are talking about two string types, then this is definitely a
case where there is little or no abstract difference, and I would
far rather see:

    User_Name := +"Robert Dewar";

than

    User_Name := A2Jstr ("Robert Dewar");

the extra characters in the latter line add no enlightenment to the reader
of significance.

(and personally I find this habit of making local abbreviations very
annoying, since all too often these abbreviations are totally uncontrolled,
and different programmers choose different abbreviations in different
places, UGH! For my taste, if an abbreviation is clear, then use it
universally, and name this package by its abbreviated name in the first
place.

I understand and appreciate the position that abbreviations should be avoided.
I understand and appreciate the position (and it is my own position) that
abbreviations are often quite reasonable.

I find the use of global lengthy names and local abbreviations a horrible
compromise that gets the worst of both worlds. Yes, I know it is a very
standard convention, and indeed no rule is absolute for me, so occaisionally
it makes sense (have a look at the GNAT runtime specs to get a feel for
when I feel it is OK), but I find many programs very much overuse this
technique.

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Anonymous]

<01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>
<01bd1ebc$3bb2cb20$20f382c1@xhv46.dial.pipex.com>

Robert Dewar presents some good reasons to use "+" for conversion
operators, and my experience with large systems presents some good
reasons not to. I'm still undecided, and welcome further arguments from
either side (or the middle).

What I would like to see is the ability to use the type name for
conversion operations. I realize I did not submit a revision request for
this, so I have only myself to blame. Then user-defined conversions
would be the same as predefined conversions:

I : Integer := Get;
F : Float   := Float (I); -- Predefined conversion uses type name

type George is ...;
type Martha is ...;

function George (Value : Martha) return George;

M : Martha := Get;
G : George := George (Martha);


Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"I blow my nose on you."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Robert Dewar]

<<Robert Dewar presents some good reasons to use "+" for conversion
operators, and my experience with large systems presents some good
reasons not to. I'm still undecided, and welcome further arguments from
either side (or the middle).
>>

Don't misread what I said, I never said that "+" *should* be used, or that
it should *not* be. Why do people always look for simple minded rules (don't
answer I know the answer :-)

The proper rule is use "+" when it is a good idea to use "+", and don't use
it when it does not help readability. Sorry, I can't tell you objectively
how to make this decision!

As for using the type name, well yes, you could add this, but to me I
find it quite reasonable to do

   type Node is ...

   function To_Node (X : blabla) return Node ...

Seems to read fine to me!

Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator

[Tucker Taft]

Terry J. Westley (westley@calspan.com) wrote:

: Does anyone know who's idea it was to rename the
: Interfaces.Java.Ada_To_Java_String function to the "+"
: operator in the Intermetrics Java bindings?  I'm
: using the Aonix ObjectAda translator but assume that
: the Java class library came from Intermetrics.

: Thanks much for this clever little idea.  IMHO, it
: really improves ease of use and code readability. 

: Does this idea originate with the Java work at
: Intermetrics or does it predate it?

This idea has been around for quite a while.

: I find the inverse of + useful as well:

:    function "-" (s : String_Ptr) return String
:       renames Interfaces.Java.Java_To_Ada_String;

: Does anyone think this is a misuse of operator
: overloading?

As with Robert Dewar, I prefer using "+" for such conversions,
independent of direction.  Overloading figures it out.

I wouldn't want to see "+" used all over the place, but
it certainly comes in handy for relatively "trivial" conversions
that have to be used in many contexts.

: -- 
: Terry J. Westley, Principal Engineer
: Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225
: westley@calspan.com   http://www.calspan.com/

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA