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/24 Message-ID: <335F5971.6375@elca-matrix.ch>#1/1 X-Deja-AN: 237204201 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> Organization: ELCA Matrix SA Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1997-04-24T00:00:00+00:00 List-Id: Robert A Duff wrote: > I think I agree that "=" should compose, in the sense that composite > types call the user-defined "=" of their components, and the predefined > "=" doesn't "re-emerge" in generics. But how far do you think we should > carry this? E.g. if "=" is redefined for a scalar type, does that > affect case statements on that type? After all, case stms check the > case expression for equality with some values. What about operators > other than "="? If "/" is redefined for an integer type, should > Text_IO.Integer_IO know about it? It might well make Put(some-integer) > do the "wrong" thing, since the generic might need to divide by 10. Yes, I would affect case statements, and also allow case for types other than discrete types, such as strings, defining them as equivalent to an if elsif sequence, with the selector expression being evaluated only once. One can still keep the advantage of having to cover all possible values when the selector's subtype is static and discrete with no "=" redefinition. Otherwise, there would be a when others => null by default as the last choice. For instances of predefined packages such as Text_IO.Integer_IO with types whose arithmetic has been messed with, I think it's OK if they don't work correctly. It's easy to make the few needed type conversions to make sure IO works with such types, which require special care anyway. 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. > If I redefine "<" on a scalar type, should "<" on an array-of-that-type > call it? Yes.