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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,436e4ce138981b82 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-12 10:07:25 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!cyclone.bc.net!sjc70.webusenet.com!news.usenetserver.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 12 Mar 2004 12:07:20 -0600 Date: Fri, 12 Mar 2004 13:07:20 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: abstract sub programs overriding References: <1078839257.157439@master.nyc.kbcfp.com> <5cmr40t76va200betf07b7bd6er05ltto9@4ax.com> <1078845298.702789@master.nyc.kbcfp.com> <0ipr40thtf86b520a0qdi003aj87gtuhd4@4ax.com> <1078849973.701176@master.nyc.kbcfp.com> <1078924150.268074@master.nyc.kbcfp.com> <1079014276.527406@master.nyc.kbcfp.com> <67u0505uu3gfmlt8p28e9jkaco0nljquut@4ax.com> <1079019616.621636@master.nyc.kbcfp.com> <1079026002.840030@master.nyc.kbcfp.com> In-Reply-To: <1079026002.840030@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-2SNUwoB3t/7kpNq9XGiBKVLjYDoEZoAJsq7tTxCxCwR2Fl50HqLnrGw4bKwGYrB3xlkWA2OcK+Q6t2K!K3wmMzFlc+Hd69ldi80ZV5AucgORzIRgpyWzAaXSpM+tk9R123/BMCAMFvcA3g== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:6278 Date: 2004-03-12T13:07:20-05:00 List-Id: Hyman Rosen wrote: > But the distinction between classwide objects and non-classwide objects > exists only in your universe. In Ada you can always view-convert an object > into its classwide type. In Ada every tagged object is a member of a single, non-abstract, specific type. You can have a view of an object which is class-wide, and you can have parameter or variable names of objects which take their type from the initial value. But every object has one type for its entire life no matter how many assignments and/or view conversions are done. Yes, again, you can play unsafe programming games that change an object's tag, and thus its type. But such code is as implementation specific and unsafe as the name implies. There are similar, but safer, tricks you can play using types with discriminated types. But now you are using mechanisms which are designed to be implementation independent, and which for the most part are. Some representation clause for such types may not be accepted by all compilers, but that is a portability issue not a safety issue. Let me move from the abstract to a specific case. Let's say I have a persistent data type, where the necessary data is read from a database, and if it is changed, it is written back. Normally such a class will be written so that any types derived from the type will be initialized correctly, and in fact the author of an extension doesn't even need to be aware of the process used to do the initialization. But what if there is a type extension which requires more data to be persistent. The alternatives are for the new type to use a separate database, or to extend the entry in the existing database for objects of the new type. These two approaches will require different code for the child's type Initialize procedure, and in one sense that is why there are several different common idioms. If you use a separate database, then the parent initialize can be called last. If the approach used is to have a combined database, the approach will usually be to never call the parent's version of Initialize. However, there are some cases where you can call Initialize for the parent, then do additional reads for the child type. What happens if the call to the parent Initialize fails? If there is no local handler, an exception will propagate out of Initialize, and the scope containing the object will be exited without the object ever becoming fully initialized. Sorry about that, but there really is no choice. Again to get specific, assume that the disk that contains the database is off-line, or the DBMS is not running, or the user didn't provide the right database password on the command line or whatever. If your design for Initialize is reasonable it will print a message that gives the user a hint about what is wrong, and then exit the program (or propagate the exception outward). The problem occurs if you put a handler for the exception inside Initialize, and although you try to correct the problem, you fail--but don't re-raise the exception. This is the failure case of interest apparently to Hyman Rosen, but which I fail to see as a language design issue. You can just as easily initialize the object with garbage or put junk in an access value. They are all implementation bugs that may only occur in the mind of the programmer. Why do I say that? Because without good specification, what the program is expected to do in that case is something that only exists in the mind of the programmer, and can only be checked by a mind reader, not a compiler. If you do have a good specification, then you can use a tool like SPARK to map the specifications to the code, and mismatches become machine checkable. You don't even have to use something as heavyweight as SPARK, if there is a question you can write checks using 'Valid at the end of your Initialize procedure. In many cases, the compiler can determine at compile time that particular components of the object are always initialized, and optimize the calls away. However, remember that we are not talking ordinary cases here. This is only really appropriate in an error handler that otherwise would not do a re-raise. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke