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: 1108a1,37e6dbf5e31f6da0 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,37e6dbf5e31f6da0 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,37e6dbf5e31f6da0 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,37e6dbf5e31f6da0 X-Google-Attributes: gid10db24,public X-Google-Thread: ff6c8,37e6dbf5e31f6da0 X-Google-Attributes: gidff6c8,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Software Engineering News Brief Date: 1996/11/09 Message-ID: #1/1 X-Deja-AN: 195512593 references: <561dg9$h2g@news2.delphi.com> organization: New York University newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-11-09T00:00:00+00:00 List-Id: tmoran says " Extending the range of Year_Number with a compiler switch might or might not be a good idea, but turning off constraint checking either locally on calls to Split, Time_Of, "+", "-" etc with a Pragma, or globally with a compiler switch, is what I had in mind. (Obviously Split et al must be coded to properly handle such shenanigans, but we're assuming here that a vendor is specifically trying to allow extension of the usual range.)" >From bad to horrible :-) The idea of encouraging people to write erroneous programs is truly a bad one. Remember that pragma suppress does NOT, despite its name, promise to suppress exceptions. It simply allows the compiler to assume that the check in question will not be violated, i.e. that any program execution containing a failure of the check is erroneous. For a vendor to allow you to exceed the range of Year_Number in this manner would to me be an extension of the language, and a highly undesirable one. I will repeat my earlier position, the only thing that makes sense is to have a separate package that provides an extended year range. if you really want to get into the language extension business, you can have a switch that substitutes this extended calendar for the regular one, but that seems a poor choice to me, much better to just have a separate package called Extended_Calendar, or somesuch. (although I must say, I can't see this being at the top of any implementors priority list :-)