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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,131f06967722ab4b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexander E. Kopilovich" Newsgroups: comp.lang.ada Subject: Re: Ada 2005? Date: Tue, 21 Dec 2004 04:26:34 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1103592361 32750 212.85.156.195 (21 Dec 2004 01:26:01 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Tue, 21 Dec 2004 01:26:01 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from jayessay at 20 Dec 2004 18:44:14 -0500 X-Mailer: Mail/@ [v2.45 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-Original-Content-Transfer-Encoding: 7bit Xref: g2news1.google.com comp.lang.ada:7115 Date: 2004-12-21T04:26:34+03:00 jayessay wrote: > "Dmitry A. Kazakov" writes: [...] > > The point is that: > > > > 1. Prefix notation is misleading > > Not to mention inflexible and limiting. And how about the following alternative (which was posted to Ada-Comment in June 2003) ? --------------------------------------------------------------------------- !summary An alternative syntax is proposed here for AI-252. This alternative uses new attribute instead of extension for meaning of dot-qualification, which is currently proposed in AI-252. This text assumes the context of current AI-252. !proposal Let us introduce new attribute Method, which always must be followed by dot and operation, i.e. Object'Method.Operation for example: type T is ... ; function F(A1 : T; A2 : Integer) return Integer; procedure P(A1: T); ... X : T; Actual_A2 : Integer; F_Result : Integer; ... F_Result := X'Method.F(Actual_A2); ... X'Method.P; Conceptually, the attribute Method returns a record -- the table of all relevant methods; some analogy with C++ code is present here, although the major difference is obvious: contents of this table depends not only on the object's type, but on surround and visibility rules also. Basic visibility rules for Operation may stay as they are stated currently in AI-252, but with additional option: a programmer can explicitly list all visible packages for a particular subtype using appropriate "for...use" statement: for Subtype'Method use Package1 [, Package2, ..., PackageN]; Such explicit statement overrides basic visibility rules for all Object'Method.Operation expressions where Object belongs to Subtype. Further, with this approach we may easily provide a denotation for the component-on-demand abstraction, that is, unified notation for an externally immutable view of a data component and a function; all we need for this is another attribute Property, which should be used the same way: Object'Property.Function_Or_DataField for example, for both type T is ... ; function F(P : T) return Integer; and type T is record F : Integer; ... end record; we can write: X : T; R : Integer; ... R := X'Property.F; Arguments for a function prefixed by the Property attribute naturally correspond indices for array data component. Further, arrays (that are indexed by controlling object type) likewise may be used in conjunction with the Property attribute (in accordance with analogy between arrays and functions, supported in Ada). For example: type String_Index is new Integer; S : String(1..10); I : String_Index; ... ... I'Property.S ... Even multi-dimensional arrays are permitted here. For example: type Cities is (Edinburgh, Glasgow, London, Paris, New_York); type Distances is array (Cities, Cities) of Float; Km_To : Distances := ...; ... ... Edinburgh'Property.Km_To(Paris) ... As for arrays of arrays, only outer array may be used, that is, the subscripts for inner arrays cannot appear. For example: type Table_Index is new Integer; type Table_Line is String(1..50); Table : array (Table_Index range 1..10) of Table_Line; I : Table_Index; ... ... I'Property.Table ... -- legal ... ... I'Property.Table(1) ... -- illegal !discussion Object.Operation syntax seems as acceptable compromise in a case when there is a controlling object. Although even then the Operation does not belong to the Object (as it belongs to a package), it is reasonable to claim that conceptually, the status of being controlling temporary gives the Object some additional rights over all its operations, and in particular, extends visibility rules for the Object. But in many cases there are no controlling objects, and in those cases this Object.Operation syntax will act against proper expression and understanding of program design and logic. Moverover, as this Object.Operation style potentially conflicts with package-orientation, which is fundamental feature of Ada 95, and as this Object.Operation notation is compulsory in most of today's mainstream languages, there is real possibility of massive and disordered mixture of those design styles if this Object.Operation notation appear in Ada. There is also anxiety about possible confusion with component notation. As Robert I. Eachus recently wrote in comp.lang.ada newsgroup (message-id <3ED056CB.8000200@attbi.com> ): "I really don't like the idea of allowing the Object.Operation format to Ada. Yeah, the compilers can usually figure it out understand it. But the potential confusion with component notation is going to confuse experienced Ada users. (And eventually other O-O language users when the actually run into component references." An alternative proposed here attains main purpose of AI-252, and it does not contest AI's propositions concerning all things except Object.Operation syntax. At the same time it establishes a deterrent for unjustified use of the feature (by extra wording), makes the expression of programmer's intent more explicit, and additionally, provides finer control over visibility and over interchangeability between operation and data field. The level of uniformity achieved with the notation proposed here is even higher than with dot-notation proposed in current AI-252 (because the arrays are included) without sacrificing traditional features and natural ways for expressing specific intentions. ---------------------------------------------------------------------------