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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8ffd9ca0013db6a7,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-10-20 23:59:18 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!cyclone-sjo1.usenetserver.com!news-out.usenetserver.com!HSNX.atgi.net!sjc-peer.news.verio.net!news.verio.net!iad-read.news.verio.net.POSTED!not-for-mail Message-ID: <39F13ED9.1EE@li.net> From: Vincent Marciante X-Mailer: Mozilla 3.0 (OS/2; I) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Redefined "=" = generic disaster? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 21 Oct 2000 02:59:38 -0400 NNTP-Posting-Host: 209.139.0.154 X-Complaints-To: abuse@verio.net X-Trace: iad-read.news.verio.net 972111552 209.139.0.154 (Sat, 21 Oct 2000 06:59:12 GMT) NNTP-Posting-Date: Sat, 21 Oct 2000 06:59:12 GMT Organization: Verio Xref: supernews.google.com comp.lang.ada:1446 Date: 2000-10-21T02:59:38-04:00 List-Id: In Ada 83, one could specify/declare a generic formal private type and then compare objects of that type without any problems - the only instance where the concept of equality could be changed is for limited private types. So in effect, when one specified a private formal one got the equality operator as a side effect and could utilize it without any surprises. Now however, in Ada 95, one _can_ redefine equality for "any type at all". Therefore, all generic unit code that previously "safely" utilized "=" of a generic formal nonlimitted type may now cause unexpected results. For example if one now has an Ada 95 abstraction such as package Ada_95_Assignable_Thing is type Thing is private; function "=" (Left, Right : Thing) return Boolean; ... end; One might expect to be able to use it when instantiating an old, fully tested generic unit that was written in Ada 83 and that compiles cleanly without any warnings and that has a spec such as generic type Something is private; package Ada_83_Abstract_Data_Type is type ADT is private; ... function Is_Equal (L,R: ADT) return Boolean; end; package body Ada_83_Abstract_Data_Type is ... function Is_Equal (L,R: ADT) return Boolean; begin return L = R; end; end; package Instance_Ada_83_ADT is new Ada_83_Abstract_Data_Type(Ada_95_Assignable_Thing); My point is that, because everything could compile correctly, one would expect that the primative "=" for type "Thing" would be utilized in "Is_Equal" but it is not. Yes, I know that people can "expect" may things that "clear" ;) should not be expected but isn't this as bad as the problem with unconstrained formal types that was fixed in Ada 95? The problem here is (said with a Brooklyn accent;) "The spec asked for a private type, so thats what I gave it but the program don't work????" Aspects (or all?) of this have been discuss under previous threads regarding "reemergence of predefined operators" and the lawyers have stated that is good reason for it but could find discussion specifically about "=". Would not having "=" reemerge be bad? If only "=" did not reemerge then this possibly wide spread problem with old code would not be an issue. BTW, I not interested in arguments that the old Ada 83 code was actually incorrect when it first written. I am interested in finding out wats to update it so that it works as one would expect ;) in Ada 95. All I can think of now is ethier add function "=" (L,R: Private_Type) return Boolean is "="; to all generic parts of the old code for all formal private types in the generic part or examine all of the bodies and search for usage of "=" of the private type and then add function "=" (L,R: Private_Type) return Boolean; to their generic part. So, after all of this, what is the best way to fix the old code? Vinny P.S. Wow its late, I hope (all/most;) of the above makes sense!