Surprise in array concatenation
in [ADA]
|
From: Robert A Duff on 24 Sep 2005 20:20 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > <adaworks(a)sbcglobal.net> wrote in message > news:zSFTe.4078$wk6.1150(a)newssvr11.news.prodigy.com... > > I recall a project where an Ada newbie, having learned about enumerated > > types, created one enumerated type that was three pages long. That is, > > the number of values in the type was so great that it took three pages > > of 11 X 14 standard printer paper to contain it. > > Hey, I resemble that remark! > > The intermediate code definition for Janus/Ada includes an enumeration of > 300 or so operations. The definition covers several pages (it has comments). > That's used as the discriminant on a giant variant record that covers more > than 6 pages. No newbies here. :-) > > It's very useful for this to be an enumeration; when new operations are > added, the case statements in the optimizer and elsewhere fail to compile > until they've been updated with the new operations. That's a short term > pain, but it avoids a lot of problems in the long run (because the > operations were added considering impacts, rather than either forgotten or > defaulted to something that's likely to be wrong). > > And, yes, Bob, it's not unusual to make arrays of (parts) of this type. You mean indexed by, not "of", I think. I don't doubt it! But I suspect you don't create very many unconstrained arrays indexed by (parts of) this type. And not empty arrays thereof. True? I agree with you that there's nothing necessarily wrong with an enumeration of hundreds. And I agree that the full-coverage rule for Ada case statements is very cool. - Bob
From: adaworks on 25 Sep 2005 13:05
"Randy Brukardt" <randy(a)rrsoftware.com> wrote in message news:zcKdnQ0Er8bYF6neRVn-qQ(a)megapath.net... > <adaworks(a)sbcglobal.net> wrote in message > news:zSFTe.4078$wk6.1150(a)newssvr11.news.prodigy.com... > > I recall a project where an Ada newbie, having learned about enumerated > > types, created one enumerated type that was three pages long. That is, > > the number of values in the type was so great that it took three pages > > of 11 X 14 standard printer paper to contain it. > > Hey, I resemble that remark! > > The intermediate code definition for Janus/Ada includes an enumeration of > 300 or so operations. The definition covers several pages (it has comments). > That's used as the discriminant on a giant variant record that covers more > than 6 pages. No newbies here. :-) > I did not mean to cast any aspersions on the knowledge and skill of those who use enumerated types intelligently. Rather, I meant to indicate that enumerated types can be easily misused by those who are not thinking about their life-cycle consequences. In the project I was referencing, we had a large number of packages that depended on the extra long enumeration type. The enumeration type was a list of weapon systems that could be engaged as necessary. Every time a new weapon was added, the entire system had to be recompiled. I suggested, and the project members agreed, that a table of weapons that could be updated outside the software would give us greater flexibility. One of the key problems in all of software practice is designing for extensibility and maintainability. We want our software solutions to evolve gracefully, over time, into more fully-featured systems, but we would like this to occur without having to do the equivalent of "open-heart" surgery every time a new feature is required. Enumerated types can have the effect of painting one's self in to a corner. Richard Riehle |