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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,27502d015551c708 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2f84446733b06aca X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,2f84446733b06aca X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Constructors for Ada (was: Converting C++ class to Ada) Date: 1996/12/13 Message-ID: #1/1 X-Deja-AN: 204019382 references: <32ADF183.7195@lmtas.lmco.com> <58npck$iku$1@goanna.cs.rmit.edu.au> <32B17EFC.4BC7@watson.ibm.com> content-type: text/plain; charset=ISO-8859-1 organization: Estormza Software mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.eiffel Date: 1996-12-13T00:00:00+00:00 List-Id: In article <32B17EFC.4BC7@watson.ibm.com>, ncohen@watson.ibm.com wrote: >> The issue I have with the language is that there is an asymmetry between >> how stack objects are initialized and how heap objects are initialized. >> >> For example, to initialize an object on the heap: >> >> type Integer_Access is access Integer; >> O : Integer_Access := new Integer'(4); >> >> Why shouldn't I be able to do that for stack objects too? >> >> O : Integer'(4); [snip] > >I don't understand Matthew's point. Why is the syntax > > O : Integer'(4); > >in any way preferable to > > O : Integer := 4; > >? After all, if LT is a limited type, it cannot be initialized in >either an object declaration or an allocator. That is, > > new LT'(X); > >is every bit as illegal as > > O : LT := X; > >and for very good reason: It entails making a copy of X. I was using that style of initialization as an analogy only. Sorry about that! The way the language is now, it's sort of like there's a predefined constructor that takes the type as an argument. For example, type T is private; constructor T (Initial_Value : in T); -- a "built-in" constructor And for objects on the heap only, I can "invoke" this constructor: X : T; O := new T'(X); What I'm asking for is a way to define other constructors, that take other than type T as an argument. For example, constructor T (File_Name : in String); Having that would allow me to do this O : T'(File_Name => "my_file.dat"); Yes, I can already do something very close to that for non-limited types - by using a function that returns a value of the type. But my motivation was being able to that for limited types too. I can't use a function to return a value of the limited type during elaboration of a limited object, so I had to invent some other way to do that. Thus the new syntax. I can't do this function Initial_Value () return T; O : LT := Initial_Value (...); because I don't have assignment for limited types. So let's solve the problem by doing this O : LT'Initial_Value (...); >Matthew suggests that it would be useful to specify parameters in the >declaration of a limited object to control how the object is >initialized. Yes. >Since it is already possible to force a limited object to >have a default initial state, and to change the object's state by >calling a procedure declared in the same package as the limited type, I see no compelling need for this. Then we have a philosophical difference. I would like to allow the user to have more control of the initial state of a limited object, by invoking the constructor of his choice. And to be able to do it in the declarative region. Maybe the need for such a mechanism isn't "compelling," but to me it's in the "really desirable" category. >(Furthermore, as stated in a previous >message, the same effect can often be achieved by deriving the limited >type from Limited_Controlled and giving the type discriminants that are >read by the type's Initialize procedure. Again, we have a philosophical difference. To me using discriminants to "initialize" an object is a misuse of the language. I don't believe discriminants should be used for that purpose. It seems to me you're fighting the language. Why fight? If you really want to custom initialize an object, why not build in a proper mechanism to do so? >> But suppose my type were limited. For example, I'd like to open a file >> during elaboration of the file object: >> >> F : File_Type'(Name => "my_file.dat", Mode => In_File); >> >> That's something I can't do now, because type File_Type is limited private. >> So I have to do this >> >> F : File_Type; >> begin >> Open (F, Name => "my_file.dat", Mode => In_File); > >What's so bad about with that? I didn't say it was bad! It's just that I wanted a uniform way of initializing objects, that applies irrespective of whether the type is limited or non-limited. The syntax rules prevent one from initializing a limited object in the declarative region (because no assignment is available). Why should initialization of limited objects have to be done differently? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant mheaney@ni.net (818) 985-1271