Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!hub.ucsb.edu!eiffel!kimr From: kimr@eiffel.UUCP (Kim Rochat) Newsgroups: comp.lang.eiffel Subject: Re: Multiple creation routines. Summary: Original proposal re-posted Message-ID: <462@eiffel.UUCP> Date: 13 Dec 90 01:10:46 GMT References: <4106@tantalum.UUCP> <1045@tetrauk.UUCP> <4212@tantalum.UUCP> <1051@tetrauk.UUCP> Organization: Interactive Software Engineering, Santa Barbara CA Lines: 196 In article <1051@tetrauk.UUCP>, rick@tetrauk.UUCP (Rick Jones) writes: > I had heard that Bertrand Meyer was going to propose some changes to object > creation for version 3, but I didn't know it had ever got as far as hard text. > > I would be very interested to see a copy of the whole proposal - could I > suggest that Bertrand (or someone on his behalf - I know he's a busy man) post > the proposal to the newsgroup. Perhaps he has made some revisions to the idea > since the initial circulation? The original proposal was distributed on comp.lang.eiffel last January (article <226@eiffel.UUCP>), which I've included below. As far as I can ascertain in Dr. Meyer's absence, there have been no changes to the proposal. Kim Rochat Interactive Software Engineering, Inc. Responses to: eiffel@eiffel.com ------------------------------------------------------------------------------- Re-posted article: ------------------------------------------------------------------------------- From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.lang.eiffel Subject: Eiffel cleanup #1: The creation mechanism Keywords: Separate operation on references from operations on objects Message-ID: <226@eiffel.UUCP> Date: 16 Jan 90 04:07:30 GMT Organization: Interactive Software Engineering, Santa Barbara CA Lines: 167 A change planned for the object creation in Eiffel -------------------------------------------------- In the tradition of glasnost' that has marked the evolution of Eiffel, this posting and one or two subsequent ones will describe the changes planned for version 3 of the language. These are cleanup changes and do not affect anything fundamental. ---------------------------------------------------------------------- |WARNING: The change described here is planned for version 3 of the | |environment. | | |Any change in the language supported by Interactive's tools | |will be accompanied by CONVERSION TOOLS to translate ``old'' syntax | |into new. Programmers will NOT need to perform any significant work | |to update existing Eiffel software. | | | |This posting is made solely for the purpose of informing the Eiffel | |community about ongoing developments. Although the posting has been | |preceded by careful reflection and internal discussions within | |Interactive, we make no commitment at this point that the features | |described here will actually be included, and, if they are, that | |their final form will be the exact one shown below. | ---------------------------------------------------------------------- Purpose of the change. ---------------------- The purpose of the change is to solve several problems at once through an improved syntax and semantics for creating objects in Eiffel. None of the problems is really major since, as indicated below, each has a reasonable solution in the current language. Some of them are small practical nuisances; others are irregularities which impair the elegance of the overall language design. Problem 1: In current Eiffel, there is only one creation procedure per class. To have more than one creation mechanism, you must use proper descendants (e.g. POLAR_POINT, CARTESIAN_POINT inheriting from POINT). Problem 2: By default, the Create procedure is not inherited. To reuse the same creation mechanism in a proper descendant, you must rely on renaming. Problem 3: There is no syntactical facility directly supporting the creation of an instance of a proper descendant. If a1 is of type A and you want to create it as an instance of B, a proper descendant of A, you must use an intermediate entity of type B. Problem 4: Normal feature applications a.f (...) act on the object associated with reference a, and cannot change that reference itself. There are, however, three exceptions: Create, Forget and Clone. Such irregularity is unpleasant. Problem 5: The ``Create'' procedure of a class has a somewhat special status. In particular, the current edition of ``Eiffel: The Language'' does not say clearly what happens if it is called unqualified by another procedure of the class. Problem 6: There is an inconsistency between the status of Clone, a creation instruction (``Clone'' itself is a keyword) and the status of copy, deep_copy, deep_clone, all of which are routines of the universal class ANY. Conceptually, however, Clone does not appear fundamentally different. Furthermore, why the instruction is written x.Clone (y) rather than x := y.clone (with ``clone'' a function) is not clear; this has been pointed out by many people. The language change ------------------- There is no more special role for a ``Create'' procedure. Instead, a class may contain a clause creation f, g, h, ... where the names listed are those of procedures of the class. These are the ones that may be used for creating instances of the class. ``Create'' ceases to be a keyword; ``creation'' becomes one. (The risk of clash with identifiers in existing classes appears minimal.) Procedures appearing in the creation list are otherwise normal. They may or may not appear in the export list. They may be introduced in the class itself or be obtained from a proper ancestor. A procedure which appears in the creation clause of a class may or may not appear in the creation clause of its proper descendants. As with the export clause, the creation clause may contain an item of the form repeat A where A is a proper ancestor; this is equivalent to a list of the creation procedures of A. There is only one creation instruction. Its most general form is x !D! f (...) where x is a read-write entity of some type C and D is a descendant of C; f must be a creation procedure of D. This creates an instance of D, applies the default initializations, calls f with the actual arguments given, and attaches the resulting object to x. D may be omitted in the most frequent case, for which it is the same as C, giving the form x !! f (...) For a class which has no creation procedure (meaning that the default initializations are sufficient to ensure the invariant), the syntax becomes simply x !! Because a creation procedure is a normal procedure, it may be used as the target of a feature call, either local or (if the procedure is exported) remote. For example, if a procedure set_polar (ro, theta: REAL) is listed in both the ``export'' and ``create'' clauses of a class, then for p of type POINT both of the following are correct, with a different semantics: p !! set_polar (1, pi/2) -- Create point with magnitude and angle given. p.set_polar (1, pi/2) -- Change point (previously created) to -- magnitude and angle given. Cloning ------- As suggested above, cloning ceases to be an instruction; a function clone: like Current is now part of class ANY. Forget will also disappear as an instruction. This is tied with another small change (having to do with ``void'' values) and will be described in another message. A note on conversion of existing software ----------------------------------------- Conversion of existing Eiffel classes will be straightforward. For a class with a Create procedure, it suffices to add a clause creation create Since ``create'' is no longer a keyword, nothing else changes. Calls of the form a.Create (...) will be replaced by a!!create (...) -- -- Bertrand Meyer bertrand@eiffel.com