comp.lang.ada
 help / color / mirror / Atom feed
From: Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
Subject: Re: Mutable parameter of a function (long ago was: Re: What evil would happen?)
Date: Tue, 06 Jan 2004 10:26:41 +0100
Date: 2004-01-06T10:26:41+01:00	[thread overview]
Message-ID: <46tkvv4thb7gong3ds93nuug8otgg5m3rb@4ax.com> (raw)
In-Reply-To: vvk9aag0tpob52@corp.supernews.com

On Mon, 5 Jan 2004 21:01:28 -0600, "Randy Brukardt"
<randy@rrsoftware.com> 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:

<Invisible> : X := <initial>;
Visible : constant X renames <Invisible>;

This is consistent and fine, because then Initialize/Finalize are
called on <Invisible>. 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



      reply	other threads:[~2004-01-06  9:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-02 17:55 Mutable parameter of a function (long ago was: Re: What evil would happen?) Alexandre E. Kopilovitch
2004-01-03  1:56 ` Robert I. Eachus
2004-01-03 11:18   ` Dmitry A. Kazakov
2004-01-04  0:58     ` Robert I. Eachus
2004-01-04 12:07       ` Dmitry A. Kazakov
2004-01-05  3:17         ` Alexandre E. Kopilovitch
2004-01-05  9:55           ` Dmitry A. Kazakov
2004-01-05 16:19             ` Robert I. Eachus
2004-01-06  3:04             ` Randy Brukardt
2004-01-06  9:32               ` Dmitry A. Kazakov
2004-01-06  3:01         ` Randy Brukardt
2004-01-06  9:26           ` Dmitry A. Kazakov [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox