Style: always declare subrountines?

Style: always declare subrountines?

[Victor Porton]

How do you consider this:

If one would always declare every subrountine of a package body in the 
specification (in the public or in the private part) this excludes the
possibility that one may mistakedly create an internal subrountine with
the same specification as a not yet implemented public procedure and 
forget to implement this public procedure and so get wrong program
behavior.

Stylistic checkers for always declaring in package specification?

Re: Style: always declare subrountines?

[sk]

Hi, 

> ... an internal subrountine with the same specification 
> as a not yet implemented public procedure ...

The "internal subroutine" IS the implementation of the 
"public procedure". 

You will not be permitted, by the compiler to do the 
following ...

--
package XXX is

   procedure AAA;

end XXX;

package body XXX is

   procedure AAA is 
   begin
      Do_Public_Operation;
   end AAA;

   procedure AAA is 
   begin
      Do_Internal_Operation;
   end AAA;

end XXX;
--

However, the following is legal ...

--
package body XXX is 

    procedure AAA_Internal is
    begin
        null;
    end AAA_Internal;

    procedure AAA_External is
    begin
        null;
    end AAA_External;

    procedure AAA renames AAA_Internal;

end XXX;

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Style: always declare subrountines?

[Victor Porton]

[Posted and mailed]

In article <mailman.1036840502.30553.comp.lang.ada@ada.eu.org>,
	sk <noname@myob.com> writes:
> Hi, 
> 
>> ... an internal subrountine with the same specification 
>> as a not yet implemented public procedure ...
> 
> The "internal subroutine" IS the implementation of the 
> "public procedure". 
> 
> You will not be permitted, by the compiler to do the 
> following ...

You misunderstood. I'm about the case when one has forgotten
to write the definition of the "public procedure", but
written in the body a "private procedure" with the same
specification.

Re: Style: always declare subrountines?

[Jim Rogers]

Victor Porton wrote:

> [Posted and mailed]
> 
> In article <mailman.1036840502.30553.comp.lang.ada@ada.eu.org>,
> 	sk <noname@myob.com> writes:
> 
>>Hi, 
>>
>>
>>>... an internal subrountine with the same specification 
>>>as a not yet implemented public procedure ...
>>>
>>The "internal subroutine" IS the implementation of the 
>>"public procedure". 
>>
>>You will not be permitted, by the compiler to do the 
>>following ...
>>
> 
> You misunderstood. I'm about the case when one has forgotten
> to write the definition of the "public procedure", but
> written in the body a "private procedure" with the same
> specification.
> 

I personally do not think you should create style rules to try
to cover for bad design. Instead, you should improve your design
process. Your design process should make sure your package
specifications are correct before you build your package bodies.

Jim Rogers

Re: Style: always declare subrountines?

[sk]

Hi,

porton@ex-code.com (Victor Porton)
> You misunderstood. I'm about the case when one has forgotten
> to write the definition of the "public procedure", but
> written in the body a "private procedure" with the same
> specification.

I do misunderstand and I am having a difficult time
imagining how the situation would occurr ...

Either you want to make a private procedure public ?
... then simply put the spec in the package spec and
obviously not what you are talking about.

Or you want two subroutines, possibly unrelated, 
one public and one private, to operate on the same 
data types etc, with the same name ?
... I would tend to do a rethink at this stage and
change data abstractions and modeling.



-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Style: always declare subrountines?

[Robert A Duff]

porton@ex-code.com (Victor Porton) writes:

> How do you consider this:
> 
> If one would always declare every subrountine of a package body in the 
> specification (in the public or in the private part) this excludes the
> possibility that one may mistakedly create an internal subrountine with
> the same specification as a not yet implemented public procedure and 
> forget to implement this public procedure and so get wrong program
> behavior.
> 
> Stylistic checkers for always declaring in package specification?

This bug hardly seems likely enough to worry about.

But if you want to do this, put the specs of the internal procedures at
the start of the package *body*, not in the private part.  For one
thing, private parts are not totally private -- child packages can see
them.  For another, putting more stuff in private parts causes more
compile-time costs.

- Bob

Re: Style: always declare subrountines?

[Frank J. Lhota]

As a general rule, I always make separate specifications and bodies for
subprograms, even if they are local to a library unit. Doing this makes it
very clear which subprograms are local and which a global. Moreover, I group
the subprogram specifications near the beginning of a package body. This
eliminates any concern over the ordering of the subprogram bodies.

Re: Style: always declare subrountines?

[chris.danx]

Victor Porton wrote:

 > How do you consider this:
 >
 > If one would always declare every subrountine of a package body in the
 > specification (in the public or in the private part) this excludes the
 > possibility that one may mistakedly create an internal subrountine
 > with the same specification as a not yet implemented public procedure
 > and forget to implement this public procedure and so get wrong program
 > behavior.


I don't see the problem, surely you would have to put the public
routines code in the body and therefore be aware of the naming of the
public routines?

 >
 > Stylistic checkers for always declaring in package specification?


I almost never do this.  I only put the interface routines in the spec
and put auxilliary routines in the body only.  This helps separate as
much as possible the implementation and the specification.  As always
there is an exception to this.  Whenever I have a controlled or
limited_controlled type, I like to put the adjust, initialize and
finalize routine declarations in the private section of the spec.  Just
a preference


I'd often like to completely separate the interface and specification
almost entirely, but that's not possible in Ada.  In fact I don't know a
language in which it is possible to do this.  It's probably a concession
to compilers or something where they have to know the implementation
details of a private type to know what they're doing, or to make it
easier for them.  It's not a big deal though!


Danx
-- 
for personal replies change spamoff to chris

Re: Style: always declare subrountines?

[Simon Wright]

porton@ex-code.com (Victor Porton) writes:

> How do you consider this:
> 
> If one would always declare every subrountine of a package body in the 
> specification (in the public or in the private part) this excludes the
> possibility that one may mistakedly create an internal subrountine with
> the same specification as a not yet implemented public procedure and 
> forget to implement this public procedure and so get wrong program
> behavior.
> 
> Stylistic checkers for always declaring in package specification?

If you use -gnaty GNAT will require specs (well, it warns if there
aren't any). But of course they only need be as local as required; so
it's common to see

  procedure Foo;
  procedure Foo is ..

in a local scope.

Re: Style: always declare subrountines?

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> How do you consider this:
> 
> If one would always declare every subrountine of a package body in the 
> specification (in the public or in the private part) 

Far too restrictive. There are many times when it is good to implement
many small subprograms in the body, that simply do not belong in the
spec, public or private. Other children of the package should _not_
see them!

This is especially true when the body requires packages that the spec
does not. Moving subprogram declarations to the spec then requires
moving the package "with" clauses to the spec. This is sometimes
illegal, due to circularity or private children issues.

> this excludes the possibility that one may mistakedly create an
> internal subrountine with the same specification as a not yet
> implemented public procedure and forget to implement this public
> procedure and so get wrong program behavior.

If the public interface is not present, you'll get a compilation
error, not "wrong behavior".

Hmm, I guess you can get "wrong behavior" if you forgot to overload or
override a subprogram in the spec, and thus get the "parent"
subprogram. Is that what you are talking about? In that case, you can
sometimes make the parent procedure abstract

> Stylistic checkers for always declaring in package specification?

As others have said, there is no substitute for a good design process.

-- 
-- Stephe

;Re: Style: always declare subrountines?

[Richard Riehle]

Victor Porton wrote:

> How do you consider this:
>
> If one would always declare every subrountine of a package body in the
> specification (in the public or in the private part) this excludes the
> possibility that one may mistakedly create an internal subrountine with
> the same specification as a not yet implemented public procedure and
> forget to implement this public procedure and so get wrong program
> behavior.

My own own preference for internal subprograms that have no
entry in the specification  to promote them to a private package
specification.   This promotes reuse, enhances maintenance, and
allows extensibility.   For example, consider:

            package P1 is
                procedure Q ...
                procedure R ...
                function    S   return ...
           end P1;

           package body P1 is
               function T ... return  ... is ... end T;
               function Z ... return  ... is ... end Z;
               function W ... return  ... is ... end W;
               procedure Q ... is ...   end Q;
               procedure R ... is ...   end R;
               function    S ... return ... is ...   end S;
          end P1;

The three functions, T, Z, and W can be promoted to a private package
specification,

            private package P1.Utilities is
               function T ... return  ... ;
               function Z ... return  ... ;
               function W ... return  ... ;
          end P1.Utilities;

Now package body for P1 is as before but,

          with P1.Utilities;
          package body P1 is  ... end P1;

For some reason, we continue to see some designers
miss out on the potential for decomposing their systems
so they can make the best use of private child library units.
The fundamental design policy can be stated as: only include
in package body the code corresponding directly to entries
in the specification.  Everything else should have its
own specification and implementation.

Richard Riehle

Re: Re: Style: always declare subrountines?

[John English]

Richard Riehle wrote:
> My own own preference for internal subprograms that have no
> entry in the specification  to promote them to a private package
> specification.   This promotes reuse, enhances maintenance, and
> allows extensibility.   For example, consider: [...snip...]

One thing that always bugs me is that private packages can only be
accessed from the body of a public package. What would be nice to
be able to do sometimes is:

  with P.Implementation;
  package P.Public is
    type T is private;
    ...
  private
    type T is
      record
        X : P.Implementation.Stuff;
      end record;
  end P.Public;

Unfortunately P.Implementation can't be a private package here. (I
seem to remember someone saying that there was an AI that addressed
this problem; can anyone point me at it if this is true?)

Another gripe: it would sometimes be nice to be able to say "type T
renames P.Implementation.Stuff", but the standard trick of using a
subtype to rename doesn't work because T is declared as a type, not
a subtype. Grrr!

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Style: always declare subrountines?

[Lutz Donnerhacke]

* John English wrote:
> accessed from the body of a public package. What would be nice to
> be able to do sometimes is:
>
>   with P.Implementation;
>   package P.Public is
>     type T is private;
>     ...
>   private
>     type T is
>       record
>         X : P.Implementation.Stuff;
>       end record;
>   end P.Public;
>
> Unfortunately P.Implementation can't be a private package here.

How should the P.Public user know how an element of type T has to be
allocated? If you only change P.Implementation, the body of P.Public has to
be recompiled, but not the parts depending on P.Public only.

Re: Style: always declare subrountines?

[Vincent Marciante]

John English wrote:
 
> Unfortunately P.Implementation can't be a private package here. (I
> seem to remember someone saying that there was an AI that addressed
> this problem; can anyone point me at it if this is true?)

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13
-- 
Vinny

"private with" proposal

[Vincent Marciante]

"with private" is a proposed addition to Ada; see 
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13

I do not understand why the extra syntax (adding "private" to
the context clause) is necessary.  Can't the rules be simply
be changed as outlined in the proposal?  If compilers at this 
time already do enough to recognize withing a private unit 
in a public spec couldn't they be made to allow usage of withed 
private units only in the private part (and body)?

-- 
Vinny

Re: "private with" proposal

[David C. Hoos, Sr.]

"Vincent Marciante" <INALID_EXCEPT_FOR_marciant@earthlink.net> wrote in
message news:3DE66447.2D6@earthlink.net...
> "with private" is a proposed addition to Ada; see
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13
>
> I do not understand why the extra syntax (adding "private" to
> the context clause) is necessary.  Can't the rules be simply
> be changed as outlined in the proposal?  If compilers at this
> time already do enough to recognize withing a private unit
> in a public spec couldn't they be made to allow usage of withed
> private units only in the private part (and body)?
As I understand the proposal, "with private" would allow the
unit to be referenced only in the private part of the specification
(and in its body) regardless of whether the privately "withed"
unit is private or public.
David
>
> --
> Vinny

Re: "private with" proposal

[Vincent Marciante]

"David C. Hoos, Sr." wrote:
> 
> "Vincent Marciante" <INALID_EXCEPT_FOR_marciant@earthlink.net> wrote in
> message news:3DE66447.2D6@earthlink.net...
> > "with private" is a proposed addition to Ada; see
> > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13
> >
> > I do not understand why the extra syntax (adding "private" to
> > the context clause) is necessary.
  
<snip>

> As I understand the proposal, "with private" would allow the
> unit to be referenced only in the private part of the specification
> (and in its body) regardless of whether the privately "withed"
> unit is private or public.
> David

Yes, I get that from reading the proposal.  But the extra syntax 
couldn't be any real benifit.   I mean one would still be able to
plain old "with" a (non-private) unit even if it was only utilized
in the private part.  So, I don't buy the "documents the not for export"
_guideline_ benifit when dealing with non-private units that are 
allowed to be withed by but are not allowed to be exported by a unit.

--
Vinny

Re: "private with" proposal

[Dale Stanbrough]

In article <3DE6ECCB.650C4DCF@earthlink.net>,
 Vincent Marciante <INVALID_EXCEPT_FOR_marciant@earthlink.net> wrote:

> Yes, I get that from reading the proposal.  But the extra syntax 
> couldn't be any real benifit.   I mean one would still be able to
> plain old "with" a (non-private) unit even if it was only utilized
> in the private part.  So, I don't buy the "documents the not for export"
> _guideline_ benifit when dealing with non-private units that are 
> allowed to be withed by but are not allowed to be exported by a unit.
> 

If you have

   with private fred;
   package x is...
 
this will tell the reader more than

   with fred;
   package x is...


For example if you have the latter, and you change
fred, what will be the outcome on the rest of the
program? Will you have to change any package that withs
'x'?

If you have 

   with private fred;

and you change fred, you know you will not have to 
change any package that changes x.

Quite a good thing for readability.

On the other hand, any decent tool set should be able
to tell you this anyway...

Dale

Re: "private with" proposal

[Stephen Leake]

Vincent Marciante <INALID_EXCEPT_FOR_marciant@earthlink.net> writes:

> "with private" is a proposed addition to Ada; see 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13
> 
> I do not understand why the extra syntax (adding "private" to
> the context clause) is necessary.  Can't the rules be simply
> be changed as outlined in the proposal?  If compilers at this 
> time already do enough to recognize withing a private unit 
> in a public spec couldn't they be made to allow usage of withed 
> private units only in the private part (and body)?

You are correct, the "extra syntax" of "private" in the context clause
is not strictly necessary; the compiler and reader could figure out
what's going on.

But what is the downside of having the extra syntax? The syntax alone
is a trivial addition to the compiler; the semantics is more complex.

The upside of the extra syntax is significant; the compiler can tell
if some later maintenance code breaks a design decision; the reader
can tell that package "foo" is implementation only, and not part of
the visible spec.

So i'd prefer to keep the "with private".

In addition, there are some cases with generics where it really is
necessary, to keep the generic contract. I posted a note about that
here a while back (and to the ARG, as well).

-- 
-- Stephe

Re: "private with" proposal

[Vincent Marciante]

Stephen Leake wrote:
 
> You are correct, the "extra syntax" of "private" in the context clause
> is not strictly necessary; the compiler and reader could figure out
> what's going on.
> 
> But what is the downside of having the extra syntax?

Discussing in the same AI as the one pertaining to
visability _within_ hierarchies confuses to issue.
It would be better for its (added syntax) added value
to be justified as clearly distict from the current AI
because that way it is clearly seen as being an issue
that could have been raised even with Ada 83 which did
not have unit hierarchies.  If it _was_ something that
was considered an rejected for Ada 83 then it would be
good to discuss what ha changed now that increases it
value to the point of acceptance now.

I think other issues (my "favorite" being reemergence of
private "=" in generics) are much more important to 
be solved than adding "documentation" syntax.

> The syntax alone is a trivial addition to the compiler;
> the semantics is more complex.
> 
> The upside of the extra syntax is significant; the compiler can tell
> if some later maintenance code breaks a design decision; the reader
> can tell that package "foo" is implementation only, and not part of
> the visible spec.

I'm not convinced that an extra degree of allowed visibility 
designations is justified.  i think that hierarchies can be 
arranged so that design decisions can not be broken unless a 
unit that would otherwise _not_ have been changed ends up 
being changed.  With "with private" it would mearly be that
a unit that was being changed during maintanence was changed
inapropriately:  How would the maintainer know that some unit
that was "with privated" (Oo! I think I just coined a really 
good one) was "with privated" and not simply "withed" due to
a design architecture decision and not simply because the 
original author of the unit realized that it was only used in
the private part.  Would one then have rules like "Don't 
'with private' unless its a real design architecure decision" :^
 
> So i'd prefer to keep the "with private".
> 
> In addition, there are some cases with generics where it really is
> necessary, to keep the generic contract. I posted a note about that
> here a while back (and to the ARG, as well).

I'll try to find that note...  Okay, just (re)read it.
Although I'm not yet sure about the need for the extra
syntax within the generic part, I seems to me that even
in this case, it would still _not_ be necessary in the
context clause.  I'll think about your example an post
again if I come to any realizations regarding within the
generic part. 

-- 
Vinny

Re: Style: always declare subrountines?

[John English]

Vincent Marciante wrote:
> 
> John English wrote:
> 
> > Unfortunately P.Implementation can't be a private package here. (I
> > seem to remember someone saying that there was an AI that addressed
> > this problem; can anyone point me at it if this is true?)
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00262.TXT?rev=1.13

Thank you!

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Style: always declare subrountines?

[John English]

Lutz Donnerhacke wrote:
> 
> * John English wrote:
> > accessed from the body of a public package. What would be nice to
> > be able to do sometimes is:
> >
> >   with P.Implementation;
> >   package P.Public is
> >     type T is private;
> >     ...
> >   private
> >     type T is
> >       record
> >         X : P.Implementation.Stuff;
> >       end record;
> >   end P.Public;
> >
> > Unfortunately P.Implementation can't be a private package here.
> 
> How should the P.Public user know how an element of type T has to be
> allocated? If you only change P.Implementation, the body of P.Public has to
> be recompiled, but not the parts depending on P.Public only.

I'm not sure I understand your point here. If P.Implementation is a
public package, this is legal Ada 95. If it's a private package, it
isn't. And of course, if P.Implementation changes, P.Public has to
be recompiled (because the size of P.Implementation.Stuff might have
changed) and clients of P.Public will therefore have to be recompiled
(because the size of P.Public.T might have changed). Or are you talking
about something different to this?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Style: always declare subrountines?

[Lutz Donnerhacke]

* John English wrote:
> Lutz Donnerhacke wrote:
>> How should the P.Public user know how an element of type T has to be
>> allocated? If you only change P.Implementation, the body of P.Public
>> has to be recompiled, but not the parts depending on P.Public only.
>
> I'm not sure I understand your point here. If P.Implementation is a
> public package, this is legal Ada 95. If it's a private package, it
> isn't.

I do not think about legalness, but about recompilation.

> And of course, if P.Implementation changes, P.Public has to be recompiled
> (because the size of P.Implementation.Stuff might have changed) and
> clients of P.Public will therefore have to be recompiled (because the
> size of P.Public.T might have changed). Or are you talking about
> something different to this?

My dumb brain suggests, that a privatly declared type can be used elsewhere
in the program. If the size of this type depends on an other package, the
using package does not notice it and allocates the wrong size. (Yep, dumb.)

Re: Style: always declare subrountines?

[John English]

Lutz Donnerhacke wrote:
> 
> > And of course, if P.Implementation changes, P.Public has to be recompiled
> > (because the size of P.Implementation.Stuff might have changed) and
> > clients of P.Public will therefore have to be recompiled (because the
> > size of P.Public.T might have changed). Or are you talking about
> > something different to this?
> 
> My dumb brain suggests, that a privatly declared type can be used elsewhere
> in the program. If the size of this type depends on an other package, the
> using package does not notice it and allocates the wrong size. (Yep, dumb.)

Ah, I would hope that any compiler I use has a dependency manager that
can cope with this...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Style: always declare subrountines?

[Robert A Duff]

John English <je@brighton.ac.uk> writes:

> Lutz Donnerhacke wrote:
> > 
> > My dumb brain suggests, that a privatly declared type can be used elsewhere
> > in the program. If the size of this type depends on an other package, the
> > using package does not notice it and allocates the wrong size. (Yep, dumb.)
> 
> Ah, I would hope that any compiler I use has a dependency manager that
> can cope with this...

Indeed.  Ada compilers are *required* to make sure that such
inconsistencies do not happen.  If you try to link a program where one
file has a 64-bit type, and some other file thinks it's 32 bits, you
will get an error at link time.  Or, better, you use a command like
AdaMagic's "adabuild" or gnat's "gnatmake", which will fix the problem
automatically.

See RM-10.2(27).

- Bob

Re: Style: always declare subrountines?

[Lutz Donnerhacke]

* Robert A Duff wrote:
> Indeed.  Ada compilers are *required* to make sure that such
> inconsistencies do not happen.

Thanx.

Re: "private with" proposal

[Randy Brukardt]

Vincent Marciante wrote in message <3DEC42E0.407B@earthlink.net>...
>Stephen Leake wrote:
>
>> You are correct, the "extra syntax" of "private" in the context
clause
>> is not strictly necessary; the compiler and reader could figure out
>> what's going on.
>>
>> But what is the downside of having the extra syntax?
>
>Discussing in the same AI as the one pertaining to
>visability _within_ hierarchies confuses to issue.


The entire point is that visibility is the wrong model for this. The
syntax is tied to a legality rule (not a visibility rule), in order that
added or removing 'private' or moving a declaration from the private
part to the visible part does not silently change the meaning of a
program. (This is covered in the AI).

A secondary issue is the desire to think of the private part as a
separate part. We discussed allowing separate compilation of private
parts; in that case, 'private with' is just the context clause of the
private part.

The visibility rules are already way too complex in Ada, and your
suggestion would make them even more complex. Moreover, changing a unit
from private to non-private (or vice-versa) could silently change the
meaning of a program from one legal meaning to a different legal
meaning. (Currently, any such program is illegal, as the with would be
illegal when the unit is private; with 'private with' as currently
described, the use that causes the problem would be illegal.)

In any case, 'private with' is easy to describe, easy to understand,
easy to use, and easy to implement. A better solution (such as separate
compilation of private parts) may exist, but waiting for the perfect
solution to an important problem when we have an adequate solution that
we can use now would be a mistake.

                    Randy Brukardt

Re: "private with" proposal

[Vincent Marciante]

Randy Brukardt wrote:
> 
> Vincent Marciante wrote in message <3DEC42E0.407B@earthlink.net>...
> >Stephen Leake wrote:
> >
> >> You are correct, the "extra syntax" of "private" in the context
> clause
> >> is not strictly necessary; the compiler and reader could figure out
> >> what's going on.
> >>
> >> But what is the downside of having the extra syntax?
> >
> >Discussing in the same AI as the one pertaining to
> >visability _within_ hierarchies confuses to issue.
> 
> The entire point is that visibility is the wrong model for this. The
> syntax is tied to a legality rule (not a visibility rule), in order that
> added or removing 'private' or moving a declaration from the private
> part to the visible part does not silently change the meaning of a
> program. (This is covered in the AI).

Okay, my phraseology reflected my inadaqate apreciation for 
the distinction between visability rules and legality rules.
If the rule would be a legality rule, does that imply that
new syntax is strictly necessary?
 
> A secondary issue is the desire to think of the private part as a
> separate part. We discussed allowing separate compilation of private
> parts; in that case, 'private with' is just the context clause of the
> private part.
> 
> The visibility rules are already way too complex in Ada, and your
> suggestion would make them even more complex. Moreover, changing a unit
> from private to non-private (or vice-versa) could silently change the
> meaning of a program from one legal meaning to a different legal
> meaning. (Currently, any such program is illegal, as the with would be
> illegal when the unit is private; with 'private with' as currently
> described, the use that causes the problem would be illegal.)

Okay, suggesting specifically a visibility rule was unintended.
 
> In any case, 'private with' is easy to describe, easy to understand,
> easy to use, and easy to implement. A better solution (such as separate
> compilation of private parts) may exist, but waiting for the perfect
> solution to an important problem when we have an adequate solution that
> we can use now would be a mistake.
>                     Randy Brukardt

Thanks for the condensed explanation.

-- 
Vinny