From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!convex!killer!mit-eddie!rutgers!sri-unix!trent
From: trent@unix.SRI.COM (Ray Trent)
Newsgroups: comp.lang.ada
Subject: Re: Ada Language Change: Assignment Overloading
Message-ID: <24675@sri-unix.SRI.COM>
Date: 23 Nov 88 19:13:34 GMT
References: <8811221935.AA21274@grebyn.com>
Reply-To: trent@unix.sri.com (Ray Trent)
Organization: SRI, Menlo Park, CA.
List-Id: <comp.lang.ada>

In article <8811221935.AA21274@grebyn.com> karl@grebyn.com (Karl Nyberg) writes
>2. Why is an overloading of assignment needed?  To avoid having to
>[much flamage about overloading equals]

This standard argument against allowing the overloading of the ":="
operator ignores the fact the programmers may want *semantics*
in their type declarations instead of just syntax. Types are not 
static objects that can be completely defined at compile time,
however much the designers of Ada want to think they are.

I offer:
  type Fraction is record
    Numerator, Denominator : Integer
  end record;

The Ada apolgists would have us write the semantics for ensuring
LCD form for the type Fraction into *each and every operator*
that acts upon 2 items of this type, instead of having that 
functionality in the assignment operator, where it belongs. The point 
is, readable or not, ":=" should validly ensure the *semantics* of
every type it is defined for, as well as the pure syntactical elemants.

I claim that:
  A, B, C : Fraction;
  A := B / C;
is both more understandable and readable than:
  A, B, C : Fraction;
  Fraction_Ops.Assign(A, Fraction_Ops.Divide(B, C))

I realize that the type Fraction is a poor example. I don't have time
to explain a good example. Everyone out there that claims to be a 
programmer should be able to find one and understand it with a 
little work.

The argument that pre-processors can be used to acheive this effect is
bull. It ignores the absolute fact that *no one* maintains, reads, or
is expected to understand the processed code. This is a null argument.
If you state that your reason for disallowing assignment overloading
is to improve understandability, it is inconsistent to allow pre-processing
that gets around the problem. The original code, which is all that
anyone reads, is exactly as understandable with assignment overloading
as it is with pre-processing in an Assign(L, R) (9 extra characters, BTW,
not 6).
-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..