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

[dewar@merv.cs.nyu.edu (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.