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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: Mats Weber Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/29 Message-ID: <3365D08F.26EA@elca-matrix.ch>#1/1 X-Deja-AN: 238143558 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> Organization: ELCA Matrix SA Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Robert Dewar wrote: > > 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). This (Ada 83 code behaving in a different way with reemergence removed) is not possible with the "=" operator because of the restrictions that Ada 83 put on it. It can only happen with other operators, e.g. numeric types for which "+", "-", etc. have been redefined. The difference in behavior between tagged and non-tagged types, especially in the case where a type is not visibly tagged, is particularly ugly IMO. Just look at how the "=" problem was overlooked for all types in the language libraries. This can also cause maintenance problems: a private non-tagged type could at some time be made invisibly tagged for some reason (inheritance, make it a controlled type, ...) without changing the visible part of the package that defines it. Then all uses of the type must be checked for reemergence problems. So much for the contract model... the user of a private type doesn't care how it is implemented, right ? > 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. In this case, I think that redefining "=" for non-tagged non-limited types should have remained forbidden. > 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. I disagree, consider this: generic type Element is private; package Set is ... end; type User_Id is private; function "=" (L, R : User_Id) return Boolean; type Group_Id is private; function "=" (L, R : Group_Id) return Boolean; type User_and_Group is record User : User_Id; Group : Group_Id; end record; package User_and_Group_Sets is new Sets(Element => User_And_Group); -- Broken: predefined "=" reemerges unless User_Id and Group_Id -- are (invisibly) tagged types. To see how it is broken, look at -- what happens if User_Id and Group_Id are implemented as -- access String. I find this kind of composition all the time in production (delivered, working, got payed for it :-) code. That's what records are for, after all: the cartesian product of types.