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,6f69b1cf0f02b9ac X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-02 14:46:58 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!news.isc.org!news.gnac.net!uunet!sac.uu.net!usenet.rational.com!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada Subject: Re: Built-in types (was Re: How can I avoid Using a Semaphore? Date: Fri, 2 Feb 2001 14:01:18 -0800 Organization: Rational Software Message-ID: <95fbj1$nen$7@usenet.rational.com> References: <93ti8b$bjpps$1@ID-25716.news.dfncis.de> <9BP86.270637$U46.8654942@news1.sttls1.wa.home.com> <94563n$cb6kp$1@ID-25716.news.dfncis.de> <0Cka6.290338$U46.9207275@news1.sttls1.wa.home.com> <94co6t$v27$1@nnrp1.deja.com> <94f1a8$k9r$1@nnrp1.deja.com> <94fv9d$cjt$1@nnrp1.deja.com> <94g3tf$gb9$1@nnrp1.deja.com> <94hmgo$o2k$1@nnrp1.deja.com> <94hq56$rlv$1@nnrp1.deja.com> <94ifq8$uu$1@usenet.rational.com> NNTP-Posting-Host: ext-3074.rational.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: supernews.google.com comp.lang.ada:4888 Date: 2001-02-02T14:01:18-08:00 List-Id: Ray Blaak wrote in message news:m33deaaeks.fsf@ns40.infomatch.bc.ca... > "Mark Lundquist" writes: > > > > First I would have to figure out how to think up type names that are not so > > cheesy as "My_Int" :-) And the names shouldn't "encode" specifics about > > their implementation properties, e.g. "Int16" > > Well, you try to have a name that indicates what it is to be used for, about, > etc. e.g, > > type Instance_Count is new Natural; > > Such names should be independent of the specifics of the type itself. > > Note that you would also have the very important benefit of not accidentially > mixing up various different "whatever" integers. Hi Ray, What we're debating is what to do after all the reasonable scalar abstraction is done, if indeed there is anything left at that point. It's felt by many that it is a mistake to create a new type for every last thing under the sun (a mistake characteristic of the "wild-eyed proselyte" stage, it goes along with making everything a task :-)) Dewar asked for a counterexample, and the one I gave was of an STL-style collection insert operation that creates multiple copies of a value. This is just the kind of situation where creating a new type as you describe above is exactly what you don't want to do, because it adds absolutely no benefit whatsoever -- the only effect is to force a lot of explicit conversions. What you want is the "whatever integer", and I think Integer is fine for this because that is the meaning of Integer, while Dewar thinks I should define the "whatever integer" type explicitly. But Dewar's way does not result in gratuitous explicit conversions, because as this is intentionally the "whatever integer" type, it would be used anywhere "whatever" is needed (which certainly will not be everywhere an integer type is needed, so there will still be conversions, but those would be required anyway whether you write it his way or my way). > > > Also -- in this example, you've defined your own integer type so that you > > have the flexibility to change it later. Isn't there still always a problem, > > in that you still assume that you'll always be able to use the same type for > > all the same things? Let's say you go and use My_Int everywhere instead of > > Integer. Now you find that for certain of those uses, the current definition > > of My_Int isn't going to cut it. Well, the ability to change the definition > > of My_Int only helps you if the new definition is also what you want for all > > the uses of My_Int. > > You have the exact problem if you use the "whatever" Integer. As soon as some > of the uses differ from the "whatever" usage, then you have to rename things > anyway. Yes sir, that's absolutely right -- you have the same problem! The point I was trying to make (and didn't make very well :-) was not that Integer makes it any better, but that My_Int *doesn't* make it any better. Really, the problem with what I wrote was that I contradicted myself -- if indeed all the uses of "whatever integer" don't care, then they cannot possibly be broken if the definition changes for the sake of one usage that suddenly starts to care. But as you point out, the right solution is not to change the definition anyway, it's to use a different type. Changing the definition only obscures the code, since now we have a documented intent of "don't care" even as it now does care. So My_Int is not better with respect to "resilience to change".