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,ef86287aa487b07a X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Pb with use of redefined "=" operator Date: 1998/11/05 Message-ID: #1/1 X-Deja-AN: 408733823 Sender: matt@mheaney.ni.net References: <363F62F3.3FF7@club-internet.fr> <3640B520.D7BEEE72@elca-matrix.ch> <71sc4h$6en$1@nnrp1.dejanews.com> NNTP-Posting-Date: Thu, 05 Nov 1998 10:05:26 PDT Newsgroups: comp.lang.ada Date: 1998-11-05T00:00:00+00:00 List-Id: dewarr@my-dejanews.com writes: > In article , > Matthew Heaney wrote: > > > It is for this reason that I always implement (the full view of) ADTs as > > tagged, even if the partial view is not itself tagged. > > > I think that this is definitely a wrong approach. The fact of the matter is > that when you get to complex record types, it is rather rare to use the > equality operator meaning just component equality. It seems quite unnecessary > to introduce the overhead resulting from gratuitous tagging just in case this > (mis)use occurs. So you don't like this implementation of a stack? type Stack_Type is private; private ... type Stack_Type is tagged record Items : Item_Array; Top : Natural := 0; end record; The tagging here hardly seems gratuitous, as it's necessary to correct what is arguably a flaw in the language! > In practice I think that the problem is way overblown. Yes, it does cause > some troubles, as we see from yet another thread started up on the subject, > for those who don't know the language rules, but lots of things cause trouble > if you don't know what you are doing! I don't think this is an accurate comparison. It is pure fantasy to think that every programmer is going to remember the somewhat abstruse rules for what operators apply to a type when used as a generic actual type. The simplest approach is: o write your ADTs so that equality always composes o when importing a type as a generic formal, use only the equality operator passed in, and not aggregate comparison This way the code always works, and no one has to think - which is the entire point of abstraction!