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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 18 Oct 92 19:29:30 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!uvaarpa!soft ware.org!smithd@ucbvax.Berkeley.EDU (Doug Smith) Subject: Re: User-defined assignment Message-ID: <1992Oct18.192930.13115@software.org> List-Id: In article <1992Oct17.233209.16059@inmet.camb.inmet.com> stt@spock.camb.inmet.c om (Tucker Taft) writes: > I should probably clarify that Ada 9X *does* provide support > for user-defined initialization and finalization. This is provided > for all limited types that are derivatives (direct or indirect) > of a predefined tagged type System.Controlled. The operations > are called Initialize and Finalize, and are called at the > "appropriate" time. However, since this is restricted to "limited" > types, the user must define their own "Assign" procedure (or equivalent) > rather than rely on ":=". Yes, I know. And have in the past provided an Assign or Copy procedure. Guess how overjoyed the other programmers were to not have the ":=" work, and instead, have to call the Assign procedure (which couldn't be invoked in the declarative region.) My arguments about memory management and the inability to redefine ":=" did not gain me a lot of sympathy. So pardon me if I'm not too excited about having to continue this practice! At least now they don't have to explicitly call a Finalize procedure (and I hope will be able to use function calls.) > Therefore, this sort of user-defined assignment is > supported, and Initialize and Finalize work correctly, > in the presence of exceptions and abort. (What this means > is that Finalize is performed on an object if and only if Initialize > is performed on the object, and both Initialize and Finalize defer abort > until they complete, once they get started.) Therefore, Ada provides user-defined assignment and is only missing the Initialize and Finalize operations :-) I don't think anyone that is requesting a form of user-defined assignment means this. I'm glad Initialize and Finalize will work correctly. (By the way, when is Finalize to be invoked on values returned from a function call?) > > However, a more complete kind of support for user-defined assignmet > would allow the user to simply use the ":=" operation, and have it invoke > user-defined code. Unfortunately, this is only the tip of the iceberg. > Assignment is used implicitly in subprogram calls for by-copy parameters, > in creating aggregates, in explicit and implicit initialization, on > function return, in assignment for composite types, > etc. By restricting user-defined finalization to > limited types, we avoid all of this hairy stuff, though the programmer > can still implement roughly equivalent operations using explicit > subprograms. E.g., Assign for assignment statements, Copy for > explicit copying, Make for constructing a value (like an aggregate), > and discriminants for controlling the Initialize procedure. I've read this paragraph carefully, and to me, this is a strawman argument. Being able to define the way parameters are passed was not in the scope of my argument. The statement that assignment is `implicit' in many constructs is no doubt true--But I was talking about `explicit' assignment, which in Ada appears as an operator `:='. So to keep from complicating the argument, delete this paragraph and the previous paragraph and deal with just the ability to redefine the `:=' operator. > > Of course, this is not as friendly or flexible as being able > to define ":=" for any type, and having it used automatically > everywhere it is appropriate. However, it is significantly > easier to implement, while still giving the user the essential > capability of control over initialization and finalization, which > are sufficient to implement memory management and garbage collection. This paragraph is confusing also. The phrase, `having it used automatically everywhere it is appropriate' means what? If you mean everywhere the ":=" operation appears, GOOD! You are right, it would be friendly and flexible; and I'm glad it would be easier to implement. I WANT IT! How about a survey? > > So the question is how much Ada implementor expense and > effort is justified relative to the benefits of > the additional friendliness and flexibility. Will this > have the tendency to make Ada compilers even more complex > and expensive, or is there some straightforward approach > that can be implemented at reasonable cost that will provide > sufficient benefit. Well, I interpreted the previous paragraph to say the redefinition of explicit assignment would be significantly easier to implement. Tell me how easy. Because it would be a big improvement. However, I am one voice-- Are there any experienced programmers that actually want to redefine implicit assignment as described in the paragraphs above (silence means no)? > > S. Tucker Taft stt@inmet.com > Ada 9X Mapping/Revision Team ada9x-mrt@inmet.com (don't forget !topic) > Intermetrics, Inc. > Cambridge, MA 02138 Doug Smith smithd@software.org