From: Ludovic Brenta <ludovic@ludovic-brenta.org>
Subject: Re: Run-time accessibility checks (was: Construction initialization problem)
Date: Sat, 6 Dec 2008 09:10:49 -0800 (PST)
Date: 2008-12-06T09:10:49-08:00 [thread overview]
Message-ID: <68719e0e-af31-488a-b45c-f8db93fb70d2@v13g2000yqm.googlegroups.com> (raw)
In-Reply-To: txbc0ucekvix.ntpy85qsan7h$.dlg@40tude.net
Dmitry A. Kazakov wrote:
> It would be interesting to make a poll, how many programmers
>
> 1. start straight with Unchecked_Access
>
> 2. write Access first and then switch to Unchecked_Access after the first
> compiler message without analyzing the message
>
> 3. try to understand the message and change the design
Put me in category 3. However, changing the design isn't always
desirable because alternative designs may have unacceptable drawbacks.
> My guess is 65-30-5. Yours?
I don't know but I don't remember seeing any Unchecked_Access that
wasn't thoroughly explained in the comments near it; this would
indicate the person who wrote it was at least in category 2.
> > I've been trying to work on this problem, but the obvious solutions would
> > require full dynamic accessibility checks, including passing the
> > accessibility of all by-reference parameters -- and that is way too
> > expensive to consider. Plus dynamic checks provide a new failure mechanism
> > for code; it's not clear that is an advantage.
>
> Ooch, this is the major contributor to the group 1. If I had any danger
> that X'Access might fail at run-time, I would immediately switch to
> X'Unchecked_Access.
Actually, the presence of run-time accessibility checks are the reason
that puts me in category 3. If the run-time overhead or, worse, the
possibility of failure at run-time are unacceptable, then I prefer not
to use access types at all.
> It is absolutely unacceptable to me that a correct
> program might fail at run-time because of accessibility checks.
I differ here; to me, a program that fails an accessibility check at
run time is incorrect.
> The only
> case I could buy it, if exceptions where contracted, so that I would get an
> compile-time error at some other place. Like "Constraint_Error may be
> propagated, but the contract states otherwise."
In my understanding, there is an implicit contract stating that all
subprograms may raise at least Program_Error, Storage_Error or
Constraint_Error. I accept that as a fact and keep it in mind when
designing.
--
Ludovic Brenta.
next prev parent reply other threads:[~2008-12-06 17:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-06 10:15 Run-time accessibility checks (was: Construction initialization problem) Dmitry A. Kazakov
2008-12-06 17:10 ` Ludovic Brenta [this message]
2008-12-07 8:44 ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-07 14:56 ` Ludovic Brenta
2008-12-07 19:22 ` Dmitry A. Kazakov
2008-12-11 1:03 ` Randy Brukardt
2008-12-11 9:08 ` Dmitry A. Kazakov
2008-12-11 0:55 ` Run-time accessibility checks (was: Construction initialization problem) Randy Brukardt
2008-12-11 9:48 ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-11 11:21 ` Georg Bauhaus
2008-12-11 11:40 ` Dmitry A. Kazakov
2008-12-11 22:15 ` Run-time accessibility checks (was: Construction initialization problem) Randy Brukardt
2008-12-11 22:31 ` Randy Brukardt
2008-12-13 0:49 ` Randy Brukardt
2008-12-13 9:06 ` Run-time accessibility checks Dmitry A. Kazakov
2008-12-16 1:53 ` Randy Brukardt
2008-12-16 9:28 ` Dmitry A. Kazakov
2008-12-16 22:21 ` Randy Brukardt
2008-12-17 8:54 ` Dmitry A. Kazakov
2008-12-12 9:21 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox