Re: Help: Binary operator "="

[Ken Garlington <Kennie.E.Garlington@lmco.com>]

Robert Dewar wrote:
> 
> Ken says
> 
> <<Because infix operators don't read as nice when fully qualified, of
> course...
> 
>   Some_Stack_Type.Push(Value => A_Thing.Object, Onto => A_Stack.Object);
> -- nice
> 
>   if Some_Stack_Type.Is_Empty(A_Stack.Object) ... -- OK
> 
>   if Some_Stack_Type."="(A_Stack.Object, Another_Stack.Object) then ...
>     -- not nearly as nice as
>   if A_Stack.Object = Another_Stack.Object then ...
> 
> Surely the increased readability is intuitively obvious! :)
> >>
> 
> Oh most certainly it is to me, getting rid of the silly Some_Stack_Type
> prefix on "=" and deciding that you can use other means to figure out
> where "=" comes from makes excellent sense to me.
> 
> The only trouble is, I would apply the same reasoning to the annoying
> Some_Stack_Type. prefix on the Is_Empty call. Indeed I don't see the
> difference between the two cases. Either it is a problem to have to
> find out where things are, necessitating the verbose prefixs, or it is
> not, and the situation seems the same in both cases to me :-) :-)

Which is why I characterized it as "OK" vs. "nice" in my comments. The
(admittedly thin) distinction you could draw is as follows: Infix
operators
should be extremely obvious as to their definition (at least if written
correctly). This is why it's probably OK to use some terse notation like
"+" rather than Add. Non-infix operators are slightly less obvious, so
having some additional information (like the type of stack on which they
operate) might be useful. It's not so much being able to trace the
location
of their definition as providing useful information about the operation.
I would say that, in the second case, either leaving on the name or
taking
it off would probably be all right.

The second case actually reads better if the stacks are created from a
generic abstract data object, instead of from an abstract data type, but
then other problems (like how to define "=") become a problem...

> 
> (the smileys are because this is an old discussion, hardlly worth repeating
> unless someone has something new to say :-)

It's not particularly new, but I find the whole idea of Ada style
interesting.
For a language that promotes readability, I think style should be a
central
issue. If Ada were used more, I would eventually expect a certain
standard
style to appear over time (a la "Elements of Style" for English).

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com