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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72c34c66b38e0e05 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-29 05:42:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!uni-berlin.de!dialin-145-254-036-250.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Constructors, Assignment [LONG] Date: Sun, 29 Dec 2002 14:43:07 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-036-250.arcor-ip.net (145.254.36.250) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1041169370 7548894 145.254.36.250 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:32377 Date: 2002-12-29T14:43:07+01:00 List-Id: Randy Brukardt wrote: Thank you for the response. > I think that for this proposal to get serious consideration, you'll have > to give rules to plug the many holes in it: > > -- You'd need to carefully explain why solutions based on functions (as > Nick Roberts described) are not sufficient; They cannot work when no assignment exists. Otherwise one should invent a sort of pickwickian assignment. > -- You'll need to explain how this works for controlled types (an > incompatibility there is simply not going to be tolerated); I do not think that there is any incompatibility. Initialize can be treated as an overriding of 'Initialize. > -- You'll need to determine the rules for these in generics. Your > current description would be a giant contract model violation, and that > needs to be fixed. In particular, for a generic formal private type: > generic > type Priv is private; > what 'Get_Constructor and 'Initialize routines can be called? The fact > that these are different in profile is simply not going to fly here (and > I doubt that banning the use of constructors in generic bodies is going > to be an acceptable solution). It is not a ban. It is just a contract. Priv is private, as such it has only the standard copy-constructor (because there is an assignment). No more. Why should we expect that every user-defined operation on any possible actual for Priv should be visible in the generic body? If that is an intent then one should do: generic type Priv is new Type_That_Has_Interesting_Constructors with private; Here Priv can use all primitive operations defined on Type_That_Has_Interesting_Constructors and user-defined constructors too. I suppose the fact that this works for tagged types only is not a fault of my proposal. (:-)) An we still can have nasty, but working: generic type Priv is private; with function My_Favorite_Operation (X : Priv) is <>; ... with function Priv'Get_Constraints (...) return ... is <>; with procedure Priv'Initialize (...) is <>; > -- You'll need to explain how this works in the face of disappearing > components on an assignment. That has been the problem that has killed > all previous proposals like this one. See > http://www.adaic.org/standards/95aarm/html/AA-7-6.html, paragraphs > 17.a-17.h for a discussion. It works same way it works for the controlled types. Compare: A. Controlled type assignment: A.1 Check constraints (obtained from source) A.2 Finalize target A.3 Copy bit-wise A.4 Call Adjust B. Assignment generated from a constructor B.1 Get constraints from the parameters (call to 'Get_Constraints) B.2 Check constraints B.3 Finalize target B.5 Call 'Initialize My point is that one can always generate an assignment from a constructor. I do not propose to allow user-defined assignments written in a form a subroutine. I propose that all assignments be generated out of constructors, user-defined ones inclusive. > I'd prefer making the function solution work. There is a proposal to > make it possible to initialize limited objects with a function call, > which would eliminate that objection. Yes it definitely would, because a function which result initialises an unconstructed object is just another name for constructor. However there would be also questions: 1. Will you use ":=" for limited types within a declaration with a problem to explain what is that, or just "rename"? 2. What to do with "new" for limited types, when a constructor have to be called? 3. I suppose that constructors will be allowed for Limited_Controlled only? So arrays, untagged types, tasks and protected object will remain out of reach. > Your other objection: > >>The idea that a constructor is just a function is IMO badly wrong. > Limited >>types is just one example why. Another example is class-wide types. How > to >>construct a class-wide object from scratch? To write a class-wide > function? >>But then it will never ever dispatch. A dispatching one? But the type > is >>unknown and there is no object. This is why Ada's stream attributes are >>made hard-wired. This is also why assignment is a problem. > > > The bug, IMHO, is that you can't write T'Class'Input in Ada. Its > terrible that magic is needed there, because its clear that there are > other cases where that sort of code would be useful. > > We investigated some solutions to that problem in the past. The primary > problem is how to get the object created for a particular value of > Ada.Tags.Tag. A direct approach doesn't work, because you don't know how > to initialize the discriminants (they can be different for extensions > than for the base type). However, an approach based on using the tag > value to control dispatching of a function (rather than a result object) > does work. And it is very simple to implement (as compilers are > essentially dispatching on a value of Ada.Tags.Tag anyway). However, > most people thought that inventing syntax to solve this problem was too > heavy, and there really isn't any alternative. So nothing much has been > done on this problem. > > The basic idea is to somehow figure a value of Ada.Tags.Tag, then use it > to control dispatching on a function that returns the correct kind of > object. This requires a special call: > > Obj : T'Class := Func () use Tag_Value; The question is, will dispatching without an object be useful in cases other than construction? This proposal requires new syntax. Mine Obj : T'Class (); requires only new attributes. And gives new T'Class (); subtype Specific_T is T (); almost for free. > With these two capabilities, I believe that functions provide > appropriate constructors, and you don't necessarily need to use a > 'handle' implementation. (I suspect that in practice, you often will > want to use a handle implementation anyway, but I certainly agree that > you shouldn't be forced into it.) Leveraging existing language features > is far preferable to inventing a whole new mechanism. Though it is another question, I think that there is a need to have something like user-defined anonymous access types, with the operations becoming primitive for the pointed type. But it is probably far more difficult than just constructors. -- Happy New Year, Dmitry A. Kazakov www.dmitry-kazakov.de