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,7a2d45f282a1da1c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-06 13:49:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada References: <3F3CCB0F.543478AF@adrianhoe.nospam.com.my> <3f405ef4$1_1@news.tm.net.my> <3f54bf19_1@news.tm.net.my> <_x36b.22730$su.613585@news20.bellglobal.com> Subject: Re: float with 24-bit resolution X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Sat, 6 Sep 2003 16:48:58 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1062881675 24.150.168.167 (Sat, 06 Sep 2003 16:54:35 EDT) NNTP-Posting-Date: Sat, 06 Sep 2003 16:54:35 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:42215 Date: 2003-09-06T16:48:58-04:00 List-Id: "Randy Brukardt" wrote in message news:vlhpbhsvhh5564@corp.supernews.com... > "Warren W. Gay VE3WWG" wrote in message > news:_x36b.22730$su.613585@news20.bellglobal.com... > > Randy Brukardt wrote: > > > You could "fix" that with a comment, but an explicit initializer works > > > just as well. > > > > But this also increases the maintenance cost if you change > > the nature or number of members of that object. It also > > creates a maintenance nightmare if the initialization > > defaults are changed (in the spec) but the explicit > > initialization undoes what is "correct" for it initially > > (ie. the worst case is when it compiles, but fails to > > work correctly because the incorrect initialization > > value remains, even though the spec has been corrected). > > If your project has "visible" (i.e. non-private) record types where the > components can change, it has maintenance problems to begin with. > Initializers are the least of your problems. Inside the package, > initialization should always be done with aggregates (exactly so that missed > changes cause compile-time errors). Well, I suppose when I use tagged types, the internals are usually private, so I generally don't run into this. However, I would suggest IMHO, that even the public components are much better initialized (at least by default) based upon the designer's original intent (ie. in the spec.) OTOH, if the members are public, then it is open to some question about how the members should be used 8-) In my mind it comes down to the simple engineering practice that you centralize things that are subject to change. This is why things like an error code are generally defined in one place. Sure I could define that same constant everywhere else, and make it the same initially, but it is a maintenance nightmare later when that value changes. Even worse if it can change, but still compile and go unnoticed until something fatal happens. The same principle holds for record member initialization. So I maintain that unless you have a good reason to override the default initialization, it is better left alone. > The problem here is the inconsistence of the language. Some types can be > implicitly initialized, and others cannot. That makes problems for private > types (because if you assume that they are implicitly initialized, you are > breaking privateness and/or significantly restricting the implementation (to > records and access types only). On the other hand, limited types can only be > initialized implicitly (that probably will change in Ada 200Y). Thus, it is > impossible for any rule to be completely consistent. > > I do use implicit initializers in some cases (especially for limited types, > where nothing else is possible). But I prefer to make it explicit when > possible (generally reserving implicit initialization to marking an object > as "not valid"). > > Randy. Explicit initialization is similar in principle to a non-normalized database. You have duplication of information, when the initialized values are the same. Normalized database designs are preferred (though not always achieved in practice). Conversely, normalization of data means that your data is centralized. This centralizes your "maintenance" and ensures that if you change that value that you have got it correct everywhere else that it is needed. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg