sommar@enea.se (Erland Sommarskog) (12/09/90)
Also sprach Tom H. Meyer (tom@ozmium.UUCP): (he is also >>>) >In article <1045@tetrauk.UUCP> Rick Jones (rick@tetrauk.UUCP) writes: >>>I dislike this on the grounds that it would *require* that 'Create' be a >>>keyword. I hope to see the day when classes can have more than one >>>creation routine and this seems to disallow it. >> >>Of course Create currently IS a keyword in effect. The idea of multiple >>creates is interesting, but if you needed them, would they not be >>differentiated by their parameters? > >Not necessarily. It's easy for me to envision two different creation routines >that had identical interfaces. Wait guys! Dr. has Meyer already announced this as a coming change in Eiffel 3.0. I just dug up the article in my binder. In short there is first a new clause: CREATION f, g, h .... listing all routines which can create an object. You create an object with x !D! f(...); where x is of type C and D is a descendant of C. f is a creation procedure of D. D is optional, the default being C. If D contains no creation statement breaks down to x !! (I have to admit that I don't like this syntax. I prefer words instead of symbols, but it's not me who is the langauge designer, and I know that Dr. Meyer has another opinion.) -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
rick@tetrauk.UUCP (Rick Jones) (12/11/90)
[after some net discussion ...] In article <2295@enea.se> sommar@enea.se (Erland Sommarskog) writes: > >Wait guys! Dr. has Meyer already announced this as a coming >change in Eiffel 3.0. I just dug up the article in my binder. 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? I always welcome change if it's for the better, and with advance warning of likely future direction it's not too difficult to design for change so that these things can be painlessly incorporated when they arrive. -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan
kimr@eiffel.UUCP (Kim Rochat) (12/13/90)
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
rick@tetrauk.UUCP (Rick Jones) (12/14/90)
Thank you to Kim Rochat for re-posting Bertrand Meyer's original article. It appears that I completely missed all the previous discussion on this, I think it was shortly before I started receiving News. It seems to address a lot of the points I have raised recently. I have one query though. The proposed syntax allows an object to be created using the form: x !! meaning create an "empty" object. It may be quite incorrect for an object of the class in question to be in such a state - i.e. the invariant would be violated. However, there seems to be nothing syntactically to prevent a client program from doing this, so correctness would rely entirely on invariant checking in the target class. This is a retrograde step from the current situation, where a call to the create routine at least has to provide the proper arguments. It would seem that the "creation" clause needs some way of specifying whether a default creation call is valid or not. -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan
kim@helios.enea.se (Kim Walden) (12/17/90)
In article <1057@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > I have one query though. The proposed syntax allows an object to be > created using the form: > > x !! > > meaning create an "empty" object. It may be quite incorrect for an > object of the class in question to be in such a state - i.e. the invariant > would be violated. However, there seems to be nothing syntactically to > prevent a client program from doing this, so correctness would rely > entirely on invariant checking in the target class. This is a retrograde > step from the current situation, where a call to the create routine at > least has to provide the proper arguments. > > It would seem that the "creation" clause needs some way of specifying > whether a default creation call is valid or not. Quoting from Bertrand's proposed change: >> For a class which has no creation procedure (meaning that the default >> initializations are sufficient to ensure the invariant), the syntax >> becomes simply >> x!! So a default creation call is never valid when the creation clause of the corresponding class is non-empty. The compiler will force the user to specify one of the listed creation routines (with proper arguments, if any). This is reasonable, since the presence of a creation routine normally means that some additional initial actions are necessary to ensure the invariant. In rare cases where you want to allow a default creation call as an alternative to the specified creation routines (knowing that the invariant will be satisfied anyway), you will just have to use an empty routine. Using e.g. the proposed feature `none' of class ANY (which just returns a void reference) allows this without much ado: class C export ... creation f1, f2, none ... end class C in the client: ... x: C; ... x !! f1 (...); ... x !! f2 (...); ... x !! none; ... (Ok, since the specified creation routines can have different numbers and types of arguments.) This seems much clearer than mixing the two forms, and convinces both the compiler and the human reader that the occasional default object creation is indeed intensional. (Purists who don't like using a function for doing nothing can e.g. add an empty procedure `default' to class HERE, or maybe ISE should add it to ANY.) Note that I am only talking about the rare cases here. Most classes will have empty creation clauses, and then the short form x !! is applicable. Kim Walden Enea Data, Sweden kim@enea
bertrand@eiffel.UUCP (Bertrand Meyer) (12/19/90)
From <1057@tetrauk.UUCP> by rick@tetrauk.UUCP (Rick Jones) on the new syntax for creation: > I have one query though. The proposed syntax allows an object to be created > using the form: > x !! > meaning create an "empty" object. It may be quite incorrect for an object of > the class in question to be in such a state - i.e. the invariant would be > violated. [...]. This is a retrograde step from the current > situation, where a call to the create routine at least has to provide the > proper arguments. > It would seem that the "creation" clause needs some way of specifying whether a > default creation call is valid or not. The above form is only valid if the class has no creation routine. In this case class correctness requires that the default initializations ensure the invariant. -- -- Bertrand Meyer bertrand@eiffel.com
rick@tetrauk.UUCP (Rick Jones) (12/19/90)
In article <KIM.90Dec17113023@helios.enea.se> kim@helios.enea.se (Kim Walden) writes: | |Quoting from Bertrand's proposed change: | |>> For a class which has no creation procedure (meaning that the default |>> initializations are sufficient to ensure the invariant), the syntax |>> becomes simply |>> x!! | |So a default creation call is never valid when the creation clause of the |corresponding class is non-empty. The compiler will force the user to |specify one of the listed creation routines (with proper arguments, if any). Yes, that makes sense. Thanks for pointing it out - I obviously didn't read Bertrand's article carefully enough! -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan