comp.lang.ada
 help / color / mirror / Atom feed
From: robert_dewar@my-dejanews.com
Subject: Re: accesibility level problem
Date: 1999/02/22
Date: 1999-02-22T00:00:00+00:00	[thread overview]
Message-ID: <7aqdht$uc5$1@nnrp1.dejanews.com> (raw)
In-Reply-To: 36D06F1B.9B4ED53B@lmco.com

In article <36D06F1B.9B4ED53B@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> The relevant section is in the discussion of the 'access
attribute (I'm guessing
> cuz' GNAT won't tell us)
>
> 3.10.2(28) :
> "The accessibility level of the view shall not be
> statically deeper than that of access type A".h

Well that of course is the easy and trivial part. Any
understanding of the accessibility rules has this as a
fundamental starting point.

In a sense, if you don't have that rule down, you have
missed the entire point of the accessibility rules, and
certainly the above paragraph is not going to be
illuminating unless you already know and understand what
acessibility checking is all about.

From a lot of experience with accessibility questions, it
is not 3.10.2(28) rule that is the issue, it is the rather
complex rules that assign accessibility levels. Almost
always, the difficulty is not in understanding that the
accessibility levels must be appropriate, but rather in
understanding WHY in some particular case the accessibility
levels are incompatible.

A reference to 3.10.2(28) may satisfy a check off reference
that there be *some* RM reference, but I am afraid that in
the great majority of misunderstandings of this message,
this reference will merely be annoying, and the user will
say "yes, yes of course I know that, but WHY is are the
levels wrong/different ... in this particular case." It
is MUCH harder to give an RM reference that is really
useful in this case.

After all 3.10.2(28) is exactly a formal statement of the
GNAT error message, nothing more or less, so it adds very
little, except to send you off looking up accessibility
levels, which as I have said before is a very difficult
section, requiring a very clear idea of the dynamic and
static scoping rules.

The best advice here in my opinion is still to think about
the underlying rationale. In fact a reference to the
section in the rationale might be a whole lot more useful
than an RM reference here.

If the compiler objects with a message about dynamic
scoping, think about the following: "If this were allowed,
then in the worst case, why could it cause a dangling
pointer? You know that it could cause dangling, because
otherwise it would not be diagnosed. So the trick is to
see WHY dangling could occur, so that you know how to fix
things, usually by moving some declarations from global
to local, or vice versa.




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    




  reply	other threads:[~1999-02-22  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-19  0:00 accesibility level problem Thomas Handler
1999-02-19  0:00 ` steve quinlan
1999-02-20  0:00   ` robert_dewar
1999-02-20  0:00     ` Steve Quinlan
1999-02-21  0:00       ` robert_dewar
1999-03-01  0:00     ` Robert A Duff
1999-03-02  0:00       ` Thomas Handler
1999-02-21  0:00   ` Thomas Handler
1999-02-21  0:00     ` Steve Quinlan
1999-02-22  0:00       ` robert_dewar [this message]
1999-02-22  0:00     ` robert_dewar
1999-02-22  0:00       ` Thomas Handler
replies disabled

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