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,3bf50ede73cff892 X-Google-Attributes: gid103376,public From: wfrye@mnsinc.com (William Frye) Subject: Re: Operators Questions Date: 1996/11/07 Message-ID: <55smnk$sta@news1.mnsinc.com>#1/1 X-Deja-AN: 195071741 distribution: inet references: <3275D478.5952@eurocontrol.fr> <32766B6F.3C37@watson.ibm.com> organization: Monumental Network Systems newsgroups: comp.lang.ada Date: 1996-11-07T00:00:00+00:00 List-Id: Norman H. Cohen (ncohen@watson.ibm.com) wrote: : Richard Irvine wrote: : > : > Ada allows overloading of the predefined operators : > but not definition of new operators. : > Sometimes code could be made more readable if it : > were possible to define new operators, e.g. : > : > if aTimeInterval encloses anotherTimeInterval : > then -- It is clear which interval encloses which. : > ... : > : > instead of : > : > if encloses(aTimeInterval, anotherTimeInterval) : > then -- Which interval enclosed which? : > -- One has to look at the declaration of : > -- the function. : > -- One could use formal parameters, but : > -- then things start to get long-winded. : > ... : Named notation helps: : if Encloses (Outer => A_Time_Interval, Inner => : Another_Time_Interval) then I disagree totally here. IMNSHO named notation here only serves to make a strained, unnatural construction enven more strained and more ridiculously long winded. With code and comments for any usable size module already pushing reasonable limits in size we need extra characters in our code like we need a "new edition of the Wpanish Inquisition." (Incidentally, from my background in maintainence programming I have developed a rule of thumb, If a module doesn't fit on two pages(which is the limit I can get to spreading a listing on a table) then the developer had better give GOOD reasons for the length.) : -- : Norman H. Cohen : mailto:ncohen@watson.ibm.com : http://www.research.ibm.com/people/n/ncohen