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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/28 Message-ID: #1/1 X-Deja-AN: 238064549 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-28T00:00:00+00:00 List-Id: Mats said <,I think that the argument of backward compatibility with Ada 83 is not that important (just my opinion). I think that if someone redefines an operator for a type, then he probably has a good reason to do so, and that operator becomes part of the abstraction provided by that type and must stick with it wherever the types goes, with no exception. >> To ignore the compatibility issue here would have been a serious mistake. What frequently happens is that in the body, where a private type is visible, you don't really want the redefined equality at all, but you get it some of the time, and you have to convert etc to get rid of it, which of course is necessary in both Ada 83 and Ada 95 code. But if you extend the reach of this equality operator, then it will extend into these bodies -- and that easily cause incomaptibilities of the worst possible kind (i.e. Ada 83 code would compile fine, but give subtly different results). The design process of Ada 9x was, quite properly in my view, extremely conservative with respect to this kind of incompatibility. It was considered to be worth while incurring some such isntances for 8-bit characters (which in legal terms were allowed in Ada 83 anyway), but certainly not for tagged types. I must say that I here a lot of sturm und drang with respect to this issue (equality not composing), but I must say I have never found this a limitation in real code. Array and record equality is rare in any case, and is even rarer in cases where component equality has been redefined.