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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dd23af7a2f4f9e7c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-06 01:20:31 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Mutable parameter of a function (long ago was: Re: What evil would happen?) Date: Tue, 06 Jan 2004 10:26:41 +0100 Message-ID: <46tkvv4thb7gong3ds93nuug8otgg5m3rb@4ax.com> References: <-MWdnftXl-K1-GqiRVn-hQ@comcast.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1073380830 6397486 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:4139 Date: 2004-01-06T10:26:41+01:00 List-Id: On Mon, 5 Jan 2004 21:01:28 -0600, "Randy Brukardt" wrote: >In parameters and constants just provide a constant view of an object. But >nearly every object has a variable view as well -- you just can't explicitly >name it. Initialization and finalization are always done on a variable view >of the object - even if it is declared as a constant. Yes. A constant is just something like: : X := ; Visible : constant X renames ; This is consistent and fine, because then Initialize/Finalize are called on . The only problem is when the variable view becomes available through a constant one. Using Rosen trick, for instance. I'd like to close such gaps where possible, but it is too late of course. At least we could reduce unintentional trickery by allowing return for procedures. >That will be more obvious in Ada 200Y, because of the ability to initialize >limited objects. A constant of a limited type might contain a task; >certainly that task will run and modify its local objects without any regard >to whether it is declared in a constant or variable. The task will have a >variable view of its containing object, even if the program as a whole only >has a constant view of the object. It is no problem to me, because it would be a designer's choice whether the task should have an access to the enclosing object (Rosen trick again). I share the point that "constant/in" should be only a view. I.e. for by-reference types it does not propagate down to all components. That would be either impossible or inconsistent (considering components of access types). For by-value objects one could imagine that kind of implementation (a user-defined, of course), though that is irrelevant as long as such types have no user-defined constructor/destructor/assignement. -- Regards, Dmitry Kazakov http://www.dmitry-kazakov.de