From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 17 Oct 92 17:57:30 GMT From: dog.ee.lbl.gov!hellgate.utah.edu!caen!malgudi.oar.net!zaphod.mps.ohio-sta te.edu!darwin.sura.net!uvaarpa!software.org!smithd@ucbvax.Berkeley.EDU (Doug S mith) Subject: Re: User-defined assignment Message-ID: <1992Oct17.175730.17448@software.org> List-Id: In article <1992Oct16.231346.11881@inmet.camb.inmet.com> you write: > We do encourage people to comment on this issue. Thanks, I sent a comment. May I give you a slightly emotional reaction based on 8 years of working with Ada. Remember that a persons emotional reaction to a language greatly influences his perception of its technical merit (as is evident in the Ada vs. C++ flame wars :) > The fundamental difficulty we face is the fact that > Ada already supports exceptions and abort (something only > beginning to appear in C++), and having full support > for user-defined assignment and finalization without imposing > significant per-object space overhead requires an approach > based on some kind of program counter (PC) map of the program. > Currently Ada exception handlers are typically implemented using > PC maps, but they don't have to handle the granularity of > individual component initializations of a composite object, which > would be necessary to fully support finalization via a PC map. Then don't fully support it! How many times in Ada did a feature not get fully supported? How many times did Ada say a feature's behavior was undefined, erroneous, or implementation defined? But that didn't stop those features from getting introduced! In fact, now that we know so much more about those features, they are being enhanced (and/or restrictions lifted) in Ada9X. > Array initializations are problem the worst, since these generally > occur in a loop, and so the finalization would to be done > for only those elements for which initialiation succeeded, requiring > that the exception handler have a loop that depended on the state > of the initialization loop at the time of the exception. Or don't define what happens. So its not a perfect solution. It really doesn't seem that difficult. The loop in the declarative region has a state indicating where in the loop it is (I know the order is undefined--but let's get real), so the exception handler uses that state to determine how far finalization should be applied. Really, if this is the worst, I can live with it! This is not worth crippling the language over. In fact, this sounds like the baby (user-defined assignment) is being thrown out with the bath-water (the few problems introduced). These arguments appear valid, but they don't apply to any of the situations that I have uncovered in practice. Please don't cripple Ada9X because of these difficulties. I am currently working on the Ada Quality & Style guide. It is very common for these guidelines to explain how certain features should best be used. It also explains where certain dangerous programming practices should be avoided. If there is an Ada9X Quality & Style guide, these concerns you point out would be ideal warnings to the practicing programmer. Unfortunately, if user-defined assignment is not available, the guidelines explaining how to do memory management and garbage collection will be pretty sparce (as in Ada). There is no need to explain the correct way to use a feature that doesn't exist. Doug Smith smithd@software.org