An observation of Ada (may offend)

An observation of Ada (may offend)

[R.A.L Williams]

In article <VLADIMIR.95Mar13204932> Vladimir Vukicevic wrote:

[well-deserved dismissal of student gripe deleted]

: Speaking of why people think Ada is not a good language... it'd be nice
: if someone collected the many myths about Ada, and collected them all
: together for distribution to the unbelievers. :-)  This would simplify
: telling people about Ada, especially if all they've heard was that it's
: a "big ugly ancient language used by the government", or that it's too
: 'huge' to be worth doing anything with.

Not 'myths' but 'gripes' - its a matter of perspective!

Some years ago I spent some time writing applications in Ada 83 (of
course, it was just 'Ada' then). I wrote both workstation and embedded
applications and I formulated a number of gripes about the language at
the time. I'm now (re-)learning Ada in its Ada95 form and I'm glad to
see that many of the gripes have been addressed.

Anyway, FWIW, here's a list (in no particular order). I'd be interested 
to see how many strike a chord with other people:

a. No unsigned integers (fixed in Ada95) HCTBAEL.

b. No bit level manipulation (fixed in Ada95 but only for unsigned
ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

c. Inflexible I/O - no unformatted binary files - this may
have been fixed in Ada95 but GNAT doesn't support STREAMs yet so
I haven't been able to play with it.

d. No pointers to functions - except for the 'ADDRESS attribute which,
being a chapter 13 item is at the whim of the compiler vendor (not very
portable). This is fixed in Ada95.

e. No short cut operators (+= etc.) -- sorry, we've had this debate
already in another thread, I've heard the objections, I still like the
operators.

f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
with a language like Ada, it makes me nervous with Eiffel and C++ as
well, but, so far, I haven't tried to use those languages in embedded
systems (got a C++ one coming up soon). Its not so much needing a
run-time system, its not knowing what's in it. This is largely a compiler
vendor issue, not a language issue. HCTBAEL

g. Task overhead for serialized data access. Fixed in Ada95 with
protected types I believe, that's one of the next things to play with.

h. And a special one for Ada95: poor encapsulation of objects. I can
define a 'member function' for a class by including the class in the
parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
other features of Ada go out of their way to force the programmer to
follow 'good practice' (sometimes a matter of opinion), this seems
very lax.

HCTBAEL = "How can this be an embedded language?" 

My experience with Ada, confirmed by many people that I spoke to at the
time was that, for embedded systems at least, Ada was used as cosmetic
window dressng to a vast quantity of assembler. This was made necessary
by the shortcomings of the language for addressing low level machine
interactions. To some extent, the same was also true of X11 software
on workstations. I see from responses in other threads that this may
have changed in recent years. All I can say is about time!

: 	-- Vladimir Vukicevicn
: 	-- vladimir@intrepid.com

Bill Williams
bill.williams@gec-mrc.co.uk

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:

|> 
|> Anyway, FWIW, here's a list (in no particular order). I'd be interested 
|> to see how many strike a chord with other people:

...

|> b. No bit level manipulation (fixed in Ada95 but only for unsigned
|> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

It is trivial to write a generic package providing bit manipulation on
arbitrary integer types in Ada 83.

I would expect that it would usually be more appropriate to check if
a value was < 0 rather than checking the sign bit but I'll assume you
had a good reason.


|> 
|> h. And a special one for Ada95: poor encapsulation of objects. I can
|> define a 'member function' for a class by including the class in the
|> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
|> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
|> other features of Ada go out of their way to force the programmer to
|> follow 'good practice' (sometimes a matter of opinion), this seems
|> very lax.

If you declare a private type then the only place you can see the
implementation is from inside the package where the type is declared
(or a child package). You can declare subprograms that have parameters
of this type elsewhere but that certainly doesn't qualify as a 'member
function'.

The idea you are looking for is 'primitive operations' which a
explained in the LRM.

Robb Nebbe

Re: An observation of Ada (may offend)

[Norman H. Cohen]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
(R.A.L Williams) writes: 

|> b. No bit level manipulation (fixed in Ada95 but only for unsigned
|> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

   function Sign_Bit (N: Integer) return Boolean is
   begin
      return N < 0;
   end Sign_Bit;

|> f. Undefined 'baggage' in the run-time system. OK, this is unavoidable
|> with a language like Ada, it makes me nervous with Eiffel and C++ as
|> well, but, so far, I haven't tried to use those languages in embedded
|> systems (got a C++ one coming up soon). Its not so much needing a
|> run-time system, its not knowing what's in it. This is largely a compiler
|> vendor issue, not a language issue. HCTBAEL
...
|> HCTBAEL = "How can this be an embedded language?"

Pragma Restrictions, which must be supported (in different ways) to
conform to the real-time or safety-critical annexes, addresses this
concern in Ada 95.

|> h. And a special one for Ada95: poor encapsulation of objects. I can
|> define a 'member function' for a class by including the class in the
|> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
|> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
|> other features of Ada go out of their way to force the programmer to
|> follow 'good practice' (sometimes a matter of opinion), this seems
|> very lax.

You can do this in C++ and Eiffel too.  The only difference is
notational.  In C++, an operation Op invoked as Obj1.Op(Obj2) can only be
written inside Obj1's class, but an operation Op invoked as Op(Obj1,Obj2)
or Obj2.Op(Obj1) can be written elsewhere.  In Ada, the call would be
written as Op(Obj1,Obj2) in each case.  Whatis important is that in Ada,
C++, and Eiffel, an operation manipulating a private component/member/
feature of a type/class can only occur logically within the defining
unit.

The purpose of encapsulation is not to restrict who can be a client of a
class, but to restrict who can manipulate its internal representation.
For example, given a private type for queues, the internal representation
of a queue can only be manipulated by calling abstract operations such as
Enqueue and Dequeue.  Nonetheless, it is possible outside of the defining
package to write an Append operation, moving all the contents of one
queue to the end of the other, by calling Dequeue with the first queue as
a parameter and Enqueue with the second queue as a parameter.  This is
not a violation of encapsulation.

If there is a weakness in Ada encapsulation, it has nothing to do with
parameter lists, but with the definition of "logically within the
defining unit".  Anyone can write a child package that is "logically
within the defining unit".  (Do-While Jones once called this the "Howard
Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
access analogous to that permitted for C++ protected members in a
subclass of a definining class.  Thus the strongest degree of hiding that
Ada can provide is that of C++ "protected", not C++ "private".

One way to justify this is by thinking of the program library--er,
compilation environment--as a hypertext document with implicit links from
parent units to child units, reflecting the logical nesting of the child
units within the parent units.  Then writing a child unit is, in effect,
modifying the parent unit.  It is always possible in any language to
"break encapsulation" by modifying the defining unit!  Some development
environments may have access-control tools to restrict the ability to
modify certain units.  The proper extension of such tools to Ada 95 is
also to restrict the creation of children for such units.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: An observation of Ada (may offend)

[S. Tucker Taft]

ncohen@watson.ibm.com (Norman H. Cohen) wrote:
>
> In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
> (R.A.L Williams) writes: 
>... 
> |> h. And a special one for Ada95: poor encapsulation of objects. I can
> |> define a 'member function' for a class by including the class in the
> |> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
> |> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
> |> other features of Ada go out of their way to force the programmer to
> |> follow 'good practice' (sometimes a matter of opinion), this seems
> |> very lax.
> ...
> 
> If there is a weakness in Ada encapsulation, it has nothing to do with
> parameter lists, but with the definition of "logically within the
> defining unit".  Anyone can write a child package that is "logically
> within the defining unit".  (Do-While Jones once called this the "Howard
> Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
> access analogous to that permitted for C++ protected members in a
> subclass of a definining class.  Thus the strongest degree of hiding that
> Ada can provide is that of C++ "protected", not C++ "private".

By putting a declaration in a nested package private part, or in
the package body, you achieve hiding as effective as C++ "private."  
When introducing Ada 95 to C++ programmers, I generally explain that
Ada has three levels of visibility control, analagous to the three in
C++ -- the visible part of a package (visible to all), the private
part of the package (visible to children), and the package body
(visible to the package body itself only).  Most C++ programmers
are a bit jealous of the ability to define in Ada 95 additional
local subprograms in a package body without having to disturb the
spec.  In C++, you have to edit the class spec to add private
member functions (or play games with "friends").
 
> Norman H. Cohen    ncohen@watson.ibm.com

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <3kcflv$164a@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes:


|> If there is a weakness in Ada encapsulation, it has nothing to do with
|> parameter lists, but with the definition of "logically within the
|> defining unit".  Anyone can write a child package that is "logically
|> within the defining unit".  (Do-While Jones once called this the "Howard
|> Hughes effect": strangers claiming to be your heirs.)  Child units enjoy
|> access analogous to that permitted for C++ protected members in a
|> subclass of a definining class.  Thus the strongest degree of hiding that
|> Ada can provide is that of C++ "protected", not C++ "private".

Hiding is an all or nothing proposition; either something is hidden or
it isn't there is no "sort of hidden".

Now you can differentiate the information hiding facilities of different
langauges based in granularity, flexability, simplicity etc. IMHO "Protected"
is a quirk of C++ stemming from the lack of orthogonality between modules
and types. In other words you wind up compensating for the simplicity of the
type=module approach by increasing the levels of visibility or adding
features like nested classes and friend functions.

It isn't at all clear that "protected" is desirable in a language.

In Ada you can use whatever amount of information hiding you want through
the various uses of packages and types. In general this can be accomplished
by using child packages to provide specialized interfaces and allowing the
client to choose what they need to see. In other languages the progammer
is often required to forsee all possible uses of the abstraction or resort
to complicated schemes using multiple inheritance to increase the
flexibility of the solution.

Robb Nebbe

Re: An observation of Ada (may offend)

[Robert Dewar]

Robb Nebbe says that hiding is all or nothing. That seems quite wrong. 
That's like saying a fence in real life is either not there or is 
impregnable.

A hidden interface in a language environment is exactly analogous to the
fence. But any fence can be knocked down if you have a bulldozer.

One bull-dozer in Ada is unchecked conversion, which definitely allows
you to blow away the hiding of anything, including private parts if you
know enough! In C++ it is even easier, because you can play with pointers
so easily.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kcflv$164a@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > If there is a weakness in Ada encapsulation, it has nothing to do with
  > parameter lists, but with the definition of "logically within the
  > defining unit".  Anyone can write a child package that is "logically
  > within the defining unit".  (Do-While Jones once called this the "Howard
  > Hughes effect": strangers claiming to be your heirs.)...

    I prefer to call such a package a bastard child, and reserve the
more polite illegitimate child for cases where the parent package
specification acknowledges the possibility of unknown children.

    We debated this to great extent in Portsmouth, and I can
understand the consensus position.  But I wish that the ability to
acknowledge child units had been built into the language so that, for
example a pragma Restrictions(No_Unspecified_Child_Units); would make
sense.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An observation of Ada (may offend)

[Norman H. Cohen]

In article <EACHUS.95Mar20111527@spectre.mitre.org>, eachus@spectre.mitre.org
(Robert I. Eachus) writes: 

|>                                     But I wish that the ability to
|> acknowledge child units had been built into the language so that, for
|> example a pragma Restrictions(No_Unspecified_Child_Units); would make
|> sense.

(-:  (-:  (-: 

At one point I suggested that a package be allowed to have an "absolutely
private" part, hidden even from children: 

   package P is
      ...
   abs private
      ...
   end P;

(I took the liberty of abbreviating "absolutely" to avoid the need for a
new reserved word.)  Somebody (sorry, can't remember who) did me one
better, suggesting the following syntax: 

   package P is
      ...
   private for all with out exception
      ...
   end P;

:-) :-) :-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: An observation of Ada (may offend)

[David Weller]

In article <3knah2$p4m@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>In article <EACHUS.95Mar20111527@spectre.mitre.org>, eachus@spectre.mitre.org
>(Robert I. Eachus) writes: 
>|>                                     But I wish that the ability to
>|> acknowledge child units had been built into the language so that, for
>|> example a pragma Restrictions(No_Unspecified_Child_Units); would make
>|> sense.
>(-:  (-:  (-: 
>
>At one point I suggested that a package be allowed to have an "absolutely
>private" part, hidden even from children: 
>
>   package P is
>      ...
>   abs private
>      ...
>   end P;
>
>(I took the liberty of abbreviating "absolutely" to avoid the need for a
>new reserved word.)  Somebody (sorry, can't remember who) did me one
>better, suggesting the following syntax: 
>
>   package P is
>      ...
>   private for all with out exception
>      ...
>   end P;
>

Clever, but inelegant.  I always favored:

	package P is
	   ...
	private private
	   ...
	end P;

Of course, I've suggested MUCH worse things to the MRT :-)

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: An observation of Ada (may offend)

[Robert Dewar]

Regarding the suggestion:  pragma Restrictions(No_Unspecified_Child_Units)


Presumably the right form of this pragma is

   Pragma Child_UNits (unit, unit, unit);

with the meaning that only the named units would be allowed as children.
This is a perfectly legitimate pragma, and one that could be implemented.

But I wonder about this whole concern. After all you can always go and
edit out the "abs" of Norm's abs private, or add to the list of child
units in the above pragma.

No no, you say, your configuration management tool prevents this kind
of improper editing of the source. OK, if this is the case, then how
about this wonderful tool also restrict what child units can be supplied.

THe language can't do everything here!

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kr20s$gqq@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

  > Regarding the suggestion:  pragma Restrictions(No_Unspecified_Child_Units)

  > Presumably the right form of this pragma is

  >   Pragma Child_UNits (unit, unit, unit);

  > with the meaning that only the named units would be allowed as children.
  > This is a perfectly legitimate pragma, and one that could be implemented.

    This actually is an improvement to my suggestion, and one I
recommend to all Ada implementors.  (In fact, if Robert Dewar doesn't
get around to adding it to GNAT, I may send it to him.)

    Of course, and the reason for posting this, is that one needed
form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
I perfer the second form, what do the rest of you think?

    I guess there is a third form--to deal with the special case of a
child unit named None, you might want to use a reserved keyword here.
How about "pragma Child_Units(NOT);"?

  > But I wonder about this whole concern. After all you can always go and
  > edit out the "abs" of Norm's abs private, or add to the list of child
  > units in the above pragma.

   The point is that the software maintainer can look at the source
file and know what child units exist, not that implementers are
forbidden to add them.  If most people agree with the suggested
syntax, I will start using pragma Child_Units without any compiler
support.  (And probably quickly add the support...)

  > The language can't do everything here!

   Right, this is and should be a voluntary annotation in most
environments.  But I expect that if support is forthcoming, the
safety critical people will not only use it, their coding standards
will insist on it.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An observation of Ada (may offend)

[Peter Hermann]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3kr20s$gqq@gnat.cs.nyu.edu> dewar@cs.nyu.edu writes:
: > Presumably the right form of this pragma is
: >   Pragma Child_UNits (unit, unit, unit);
: > with the meaning that only the named units would be allowed as children.
: > This is a perfectly legitimate pragma, and one that could be implemented.

:     This actually is an improvement to my suggestion, and one I
: recommend to all Ada implementors.  (In fact, if Robert Dewar doesn't
: get around to adding it to GNAT, I may send it to him.)

:     Of course, and the reason for posting this, is that one needed
: form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
: I perfer the second form, what do the rest of you think?

I would not recommend that whole direction because
one of the strengths of the child feature is exactly the fact,
that the parent need not be touched further on.
For Ada200X, the abs private part may be more convenient (if any)
but, imho, this overburdening of the language is superfluous.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: An observation of Ada (may offend)

[David Weller]

In article <3ku7us$117l@info4.rus.uni-stuttgart.de>,
Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>Robert I. Eachus (eachus@spectre.mitre.org) wrote:
>:     Of course, and the reason for posting this, is that one needed
>: form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
>: I perfer the second form, what do the rest of you think?
>
>I would not recommend that whole direction because
>one of the strengths of the child feature is exactly the fact,
>that the parent need not be touched further on.
>For Ada200X, the abs private part may be more convenient (if any)
>but, imho, this overburdening of the language is superfluous.
>

Ah, but that's what pragmas are for, eh? :-)

The way I see it is you have three options:
1.  Anybody can extend your package
2.  Nobody can extend your package
3.  Specific "children" are permitted to extend your package

Option 1 is definitely supported in Ada95
Option 2 and 3 can be supported with Eachus' suggestion (giving a
"friend"-like pragma)

The fundamental issue is, however, can you thwart options 2 or 3?
Given the pragma Robert Eachus suggestied, the answser is "No" for
pragma Child_Units(None) and "yes" for Pragma Child_Units(..list..).
All I have to do for option 3 is create a child unit that has a
matching name.

It kinda leads me to conclude that perhaps just having a "pragma
No_Child_Units;" is the best thing to have.

Maybe this discussion should migrate to the MRT list?


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: An observation of Ada (may offend)

[Robert Dewar]

"Maybe this discussion [about pragma No_Child_Units] should migrate to the
MRT list"

I think definitely NOT, I would hate to see the MRT list cluttered up with
discussions of possible extensions etc. It should be reserved strictly for
discussing Ada 95 as it is.

It is incidentally quite easy to thwart pragma No_Child_Units; just edit
the line out of the source. As I noted in my original response, your
CM may prevent this, but if it is clever enough to do that, why can't
it be a little more clever and control fhild units.

Re: An observation of Ada (may offend)

[Tucker Taft]

Peter Hermann (ucaa2385@alpha1.csv.ica.uni-stuttgart.de) wrote:

[Various proposals relating to limiting the use of child units.]

: I would not recommend that whole direction because
: one of the strengths of the child feature is exactly the fact,
: that the parent need not be touched further on.
: For Ada200X, the abs private part may be more convenient (if any)
: but, imho, this overburdening of the language is superfluous.

Here, here.

Child units are a namespace structuring mechanism.  A fundamental 
characteristic of this structuring mechanism is that the spec of the 
parent does not depend on the children.  Furthermore, if a child unit 
is not mentioned in some "with" clause, it is as though it doesn't 
exist at all, and will not be included in the program.  Hence, adding 
an "unwanted" child has no effect on any program that does not 
explicitly mention that child in some with clause.

Adding a child is simply extending the interface of the abstraction
represented by the tree of library units.  Without child units,
this is done by entering a new version of a package into a library
after adding more subprograms to the package.  With child units, you 
can accomplish the same thing by entering the new child into 
the library.  In both cases, if you want to control access
or update to the library, then you need to use the O/S or the Ada compiler
to do it.  

Access control is not a language issue, it is a tool or O/S issue.

Note that using child units is actually *safer* than the "old" approach
where one simply edited the package that represented the entire abstraction,
since as mentioned above, the only clients that can possibly be affected
are those that explicitly add a "with" clause for the new child.
With the "old" approach where someone goes in and adds or changes stuff
in the original package, it is much less obvious which clients might
be affected.

So a pragma that lists the names of child units is the moral equivalent
to a comment at the top of a package that lists the names of all of 
the subprograms in the package.  It proves nothing, and simply creates 
busy work during maintenance, since it must be updated every time
you want to add a new child (and don't tell me somehow that your tools can
prevent me from entering a new version for the parent package, but
they can't prevent me from adding a new child).  Some kinds of redundancy
are useful, but these kinds of redundant lists are a waste of energy.

If you want a list of the children, get a list from the program library
manager (a.k.a "list directory" on GNAT).  Similarly, if you want
a list of the subprograms in a package, use "grep."  If you want to
lock out unauthorized additions or changes to *your* program library, 
use "chmod" (or whatever).

This whole thing reminds me of attempts to add silly amendments
to the US constitution ;-).

: --
: Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
: Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
: Team Ada: "C'mon people let the world begin" (Paul McCartney)

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.

Child packages

[Robb Nebbe]

In article <3ku7us$117l@info4.rus.uni-stuttgart.de>, ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
|> Robert I. Eachus (eachus@spectre.mitre.org) wrote:
...
|> :     Of course, and the reason for posting this, is that one needed
|> : form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
|> : I perfer the second form, what do the rest of you think?
|> 
|> I would not recommend that whole direction because
|> one of the strengths of the child feature is exactly the fact,
|> that the parent need not be touched further on.
|> For Ada200X, the abs private part may be more convenient (if any)
|> but, imho, this overburdening of the language is superfluous.

If you think of child packages as module extension then the logical place
to deal with issues like this is with other version control questions.

I don't see how something like who can add a child package is fundamentally
any different that who can modify a package. In my opinion a pragma
to deal with this situation would do more harm than good.

Robb Nebbe

Re: Child packages

[Keith Thompson]

In <1995Mar27.115304@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
> I don't see how something like who can add a child package is fundamentally
> any different that who can modify a package. In my opinion a pragma
> to deal with this situation would do more harm than good.

For a set of compilation units provided by a commercial vendor, the full
specification and body sources may not be available, making modification
difficult or impossible.  Adding a child unit is relatively easy.
(Some would argue that all the sources should always be made available,
but I don't think that assumption should be built into the language;
realistically, sources *won't* always be available.)

One advantage of such a pragma is that it gives users an ability that
currently only implementations have.  I think this has always been a
design goal of Ada.  (For example, unlike their equivalents in many
other languages, Character is an ordinary enumeration type and Text_IO
is an ordinary library package; users can write their own replacements
for them if desired.)

RM95-A(4) says

    The implementation may restrict the replacement of language-defined
    compilation units.  The implementation may restrict children of
    language-defined library units (other than Standard).

In a small way, this gives the language-defined units a special status.
An implementer of a set of non-language-defined units can have the
same reasons to impose such restrictions that an implementer of the
language-defined units might have.

On the other hand, the only real extra power a child unit gives you
is visibility to the parent's private part.  You can restrict this by
hiding implementation details within a *nested* private part (this is
based on something Tucker Taft briefly mentioned a while ago).

	package Black_Box is
	   type Hidden is private;
	private
	   package Inner_Black_Box is
	      type Inner_Hidden is private;
	   private
	      type Inner_Hidden is (Why_Are_You_Looking_At_Me);
	   end Inner_Black_Box;
	   type Hidden is new Inner_Black_Box.Inner_Hidden;
	end Black_Box;

Now even a private child of package Black_Box can't access the full
declaration of type Hidden.  Since child units can only be declared at
the library level, you can't declare a child of Inner_Black_Box, so its
private part is truly private.

Admittedly, this doesn't let you selectively export private types to
some units but not to others.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: Child packages

[Keith Thompson]

In <D64Lyo.ML9@thomsoft.com> I foolishly wrote:
[...]
> On the other hand, the only real extra power a child unit gives you
> is visibility to the parent's private part.
[...]

Of course, this isn't the only thing child units are good for.  If it
weren't so late at night, I'd come up with a better way to phrase that.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: An observation of Ada (may offend)

[Mark A Biggar]

In article <3ku7us$117l@info4.rus.uni-stuttgart.de> ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
>Robert I. Eachus (eachus@spectre.mitre.org) wrote:
>: In article <3kr20s$gqq@gnat.cs.nyu.edu> dewar@cs.nyu.edu writes:
>: > Presumably the right form of this pragma is
>: >   Pragma Child_UNits (unit, unit, unit);
>: > with the meaning that only the named units would be allowed as children.
>: > This is a perfectly legitimate pragma, and one that could be implemented.
>:     This actually is an improvement to my suggestion, and one I
>: recommend to all Ada implementors.  (In fact, if Robert Dewar doesn't
>: get around to adding it to GNAT, I may send it to him.)
>:     Of course, and the reason for posting this, is that one needed
>: form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
>: I perfer the second form, what do the rest of you think?
>I would not recommend that whole direction because
>one of the strengths of the child feature is exactly the fact,
>that the parent need not be touched further on.
>For Ada200X, the abs private part may be more convenient (if any)
>but, imho, this overburdening of the language is superfluous.

I don't see any reason for any of the above stuff.  A Child Package
is pretty innocuous in that unless your code does a with of the 
Child somewhere it has zippo effect on your program.  It would seem
that inspections and a little CM disipline should take care of any
problems.  And if that's not good enough your program/project already
has worse problems than added Child Packages.

--
Mark Biggar
mab@wdl.lroal.com

Re: An observation of Ada (may offend)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:    The point is that the software maintainer can look at the source
: file and know what child units exist, not that implementers are
: forbidden to add them...
:    Right, this is and should be a voluntary annotation in most
: environments.  But I expect that if support is forthcoming, the
: safety critical people will not only use it, their coding standards
: will insist on it.

As a safety-critical person, I don't have a problem with someone wanting this
pragma, but I wouldn't see us scrambling to add this to our coding standards,
either. My compiler, design tool, and CM tool all provide concise descriptions
of the structure of my application; I expect that the compiler, at least, will
continue to do so for Ada 95 and include package hierarchies in that
description.

I would be more concerned with the issue of having to modify the parent
package every time I add a child. Usually, our coding standards prohibit
references of this type, since (a) it adds cost and (b) the more items you
have to change, the greater the likelihood of inadvertantly inserting an
error.

Personally, I'm looking forward to being able to reuse more packages without
modifications. I think this will significantly improve safety (if we don't
break the compiler along the way! :)

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <3kv7g7$o7d@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

  > I would be more concerned with the issue of having to modify the
  > parent package every time I add a child. Usually, our coding
  > standards prohibit references of this type, since (a) it adds cost
  > and (b) the more items you have to change, the greater the
  > likelihood of inadvertantly inserting an error.

    As I said, what I like about this approach is that it allows you
to delay adding the pragmas until the appropriate point--sometime
between integration and FQT.  Before then, adding a child is a
detailed design decision, and the only major issue should be the need
to update the documentation.  After that point, you are in a
maintenance mode where the consequences of adding an "unanticipated"
child could be severe, and I certainly wouldn't permit it without a
through review.  Under most circumstances I can forsee, such an add-on
would walk like a kludge, and quack like a kludge.

    The major advantage of the pragma is to the maintainer.  Without
the pragma, a global search, or some documentation, he has no idea
what children are part of the unit he is maintaining.  This can save
days of maintenance time with little or no cost.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An observation of Ada (may offend)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:     As I said, what I like about this approach is that it allows you
: to delay adding the pragmas until the appropriate point--sometime
: between integration and FQT.  Before then, adding a child is a
: detailed design decision, and the only major issue should be the need
: to update the documentation.  After that point, you are in a
: maintenance mode where the consequences of adding an "unanticipated"
: child could be severe, and I certainly wouldn't permit it without a
: through review.  Under most circumstances I can forsee, such an add-on
: would walk like a kludge, and quack like a kludge.

I actually have this wacky idea that we might be able to start reusing
packages from project to project without modification, in which case I may
want to add new child
packages well after FQT. I wouldn't call it a "kludge" -- just an ability
to add new features without having to rewrite half of the package every
time I want to change the available features!

:     The major advantage of the pragma is to the maintainer.  Without
: the pragma, a global search, or some documentation, he has no idea
: what children are part of the unit he is maintaining.  This can save
: days of maintenance time with little or no cost.

If the maintainer has no tools or documentation (in our case, he has both),
this issue is the least of his problems.

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robert I. Eachus]

   I said (discussing source code changes during and after integration):

 > Under most circumstances I can forsee, such an add-on would walk
 > like a kludge, and quack like a kludge.

In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

 > I actually have this wacky idea that we might be able to start
 > reusing packages from project to project without modification, in
 > which case I may want to add new child packages well after FQT. I
 > wouldn't call it a "kludge" -- just an ability to add new features
 > without having to rewrite half of the package every time I want to
 > change the available features!

   First read what I wrote.  I can imagine cases where such a change
would be appropriate, especially during development and I said that.
I can also imagine adding a chiild unit in exactly those
circumstances.  (I can even imagine a "corporate programming standard"
which required all instantiations of generics nested in packages to be
child units of that package.--I don't encourage such a practice, but I
can imagine it. ;-) But I still believe that adding a child unit
during integration is likely to be a kludge.

   Now you just voluteered for the maintenance job, and it is hard to
get good maintainers, wonderful.  When you go to add your new child
unit, how do you know that it is not replacing another child of the
same name, which you were unaware of?  I, and many others, like the
documentation you need to be in the logical place--in the source.

 > If the maintainer has no tools or documentation (in our case, he has both),
 > this issue is the least of his problems.

    As anyone who has done software maintenance in the "real world"
can tell you, no tools and no (trustworthy) documenation is standard
practice outside the safety critical fields.  If they had good
documentation, they wouldn't have had to call you.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An observation of Ada (may offend)

[Garlington KE]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

:  > I actually have this wacky idea that we might be able to start
:  > reusing packages from project to project without modification, in
:  > which case I may want to add new child packages well after FQT. I
:  > wouldn't call it a "kludge" -- just an ability to add new features
:  > without having to rewrite half of the package every time I want to
:  > change the available features!

:    First read what I wrote.  I can imagine cases where such a change
: would be appropriate, especially during development and I said that.

I did. You said, "after integration, there's no purpose in adding this."
What if there is a follow-on project after integration? This would be
"after integration."

: But I still believe that adding a child unit
: during integration is likely to be a kludge.

Unless, of course, new requirements were received during integration, such
as a contract change proposal with a quick turnaround. Or a quick-turn
change requested by the flight test team.

:    Now you just voluteered for the maintenance job, and it is hard to
: get good maintainers, wonderful.

I didn't volunteer for the maintenance job -- quite the opposite (see below).
I volunteered to build our software in such a way that we can leverage off
of it for future programs. Isn't that what programming by extension is
supposed to do for us?

:  When you go to add your new child
: unit, how do you know that it is not replacing another child of the
: same name, which you were unaware of?

The same way I know that I am not adding a package body for a spec which
already has a package body, or should not have a package body -- I have a CM
system.

Again, if you want to use this pragma, be my guest. I wouldn't say that
it would be widely used in the safety-critical field, as was originally
stated, because safety-critical software (like other kinds of software)
has tools and processes to control changes to our software.

  I, and many others, like the
: documentation you need to be in the logical place--in the source.

We, on the other hand, work with the eventual maintainers, who tell us that
they want program structure to be documented in a clean, summary form a la
ADARTS -- not by crunching through the source.

:  > If the maintainer has no tools or documentation (in our case, he has both),
:  > this issue is the least of his problems.

:     As anyone who has done software maintenance in the "real world"
: can tell you, no tools and no (trustworthy) documenation is standard
: practice outside the safety critical fields.  If they had good
: documentation, they wouldn't have had to call you.

The maintainers for F-22 software get the same tools we use (safety critical
and otherwise) along with the data. It's required by our contract.

And no, we don't expect them to call us. We plan for organic support. We
do, however, expect to bid (and hopefully win) new programs. We would like
to use the software from the last program on these new programs. Maybe even
without modifying it.

For that matter, in another life, I did software maintenance of COBOL (eeek!)
for a chemical company. We had tools and documentation. This may not be
true everywhere, but I at least _thought_ I was in the real world. I got
paid real money, at least :)

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: An observation of Ada (may offend)

[Robb Nebbe]

In article <EACHUS.95Mar28143036@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
|> 
|>    Now you just voluteered for the maintenance job, and it is hard to
|> get good maintainers, wonderful.  When you go to add your new child
|> unit, how do you know that it is not replacing another child of the
|> same name, which you were unaware of?  I, and many others, like the
|> documentation you need to be in the logical place--in the source.

This still sounds like a version control problem rather than a language
problem. I would hope that version control systems for Ada will be able
to enforce things like requiring child packages to be in the same
library as the parent.

Robb Nebbe

Re: An observation of Ada (may offend)

[Robert Dewar]

Robert, pragma Child_Units (not) indeed!

where did your syntax rules for Ada go? this really won't do at all :-)

what do others think of the pragma Child_Units, I think I would actually
have:

  pragma No_Child_Units;

for the completely restrictive case, since pragma Child_Units; with no 
argument is not very communicative, and pragma Child_Units (not) is, as
pointed out above, unacceptable.

For those who did not see the original post, the exact proposal is now
as follows:

   Any package spec may contain one occurrence of either of the following
   pragmas (but not both!)

   pragma No_Child_Units;
   --  Any attempt to compile a child unit is rejected

   pragma Child_Units (name, name, name ...)

   --  Only the given child units can be compiled

Re: An observation of Ada (may offend)

[R_Tim_Coslet]

>For those who did not see the original post, the exact proposal is now
>as follows:
>
>   Any package spec may contain one occurrence of either of the following
>   pragmas (but not both!)
>
>   pragma No_Child_Units;
>   --  Any attempt to compile a child unit is rejected
>
>   pragma Child_Units (name, name, name ...)
>
>   --  Only the given child units can be compiled

Why not:

    pragma No_Children;
    pragma Children(name, name, name ...)

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena 

Re: An observation of Ada (may offend)

[Robert I. Eachus]

In article <135736@cup.portal.com> R_Tim_Coslet@cup.portal.com writes:

 > Why not:

 >      pragma No_Children;
 >      pragma Children(name, name, name ...)

   I hereby second the motion!

   (Although I have to wonder if maybe pragma Celibate; and pragma
Offspring(name, name, name...); should be considered. ;-)

   
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: An observation of Ada (may offend)

[celier]

>   pragma No_Child_Units;
>  --  Any attempt to compile a child unit is rejected

Why not simply use pragma Restrictions:

   pragma Resptictions (No_Child_Units);
   --  Any attempt to compile a child unit is rejected

Vincent Celier
celier@infomatch.com

Re: An observation of Ada (may offend)

[Robert Dewar]

I don't much like pragma Restrictions (No_Child_Units), since this is a
configuration pragma, and the idea of restricting child units completely
is not what this is about, yes, I know that such a pragma can be applied
to one unit, but I still don't like it!

Re: An observation of Ada (may offend)

[John DiCamillo]

ncohen@watson.ibm.com (Norman H. Cohen) writes:
>(-:  (-:  (-: 

>At one point I suggested that a package be allowed to have an "absolutely
>private" part, hidden even from children: 

>   package P is
>      ...
>   abs private
>      ...
>   end P;

>(I took the liberty of abbreviating "absolutely" to avoid the need for a
>new reserved word.)

If you really wanted to confuse the parser, how about:

   package P is
      ...
   real private
      ...
   end P;

Too bad "real" isn't a reserved word...

>:-) :-) :-)

-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: An observation of Ada (may offend)

[Larry Kilgallen, LJK Software]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:

> b. No bit level manipulation (fixed in Ada95 but only for unsigned
> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL.

Well some of us don't have Ada95 scheduled for our platforms...
...but I find that when I need to manipulate bits it is specific bit
fields rather than generic bit-algebras :-).  Representation clauses
in Ada are marvelous (although I have used similar capabilities from
other languages which don't happen to be codified in their standards).

> e. No short cut operators (+= etc.) -- sorry, we've had this debate
> already in another thread, I've heard the objections, I still like the
> operators.

I disagree, perhaps for a reason which has not been stated.  The 26 letters
and the space bar are about all that I can touch-type.  Entering any
punctuation requires looking at the keyboard, so I prefer long-cut
operators.

Larry Kilgallen

Re: An observation of Ada (may offend)

[Tucker Taft]

R.A.L Williams (bill@valiant.gmrc.gecm.com) wrote:

: h. And a special one for Ada95: poor encapsulation of objects. I can
: define a 'member function' for a class by including the class in the
: parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code,
: even a nested function hidden somewhere seemingly 'irrelevant'. Whereas
: other features of Ada go out of their way to force the programmer to
: follow 'good practice' (sometimes a matter of opinion), this seems
: very lax.

What are called "methods" in some OOPs are called "primitive 
operations" or "dispatching operations" in Ada 95.  These 
may be defined *only* immediately within the same package
spec as the type.  (If a type extension is declared in a package body or
declarative part, you can override inherited primtive ops there -- and
only there -- for that typ extension, but you can't define any new ones.)

So I don't think Ada 95 suffers from the above problem.  Perhaps
you were referring to something else, but I can't quite imagine what
problem it would be.  An example might help.  We certainly never meant
for Ada 95 to be "lax" ;-).

: Bill Williams
: bill.williams@gec-mrc.co.uk

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: An observation of Ada (may offend)

[Renaud HEBERT]

In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:
|> In article <VLADIMIR.95Mar13204932> Vladimir Vukicevic wrote:
|> 
|> [well-deserved dismissal of student gripe deleted]
|> 
|> : Speaking of why people think Ada is not a good language... it'd be nice
|> : if someone collected the many myths about Ada, and collected them all
|> : together for distribution to the unbelievers. :-)  This would simplify
|> : telling people about Ada, especially if all they've heard was that it's
|> : a "big ugly ancient language used by the government", or that it's too
|> : 'huge' to be worth doing anything with.
|> 
|> Not 'myths' but 'gripes' - its a matter of perspective!
|> 
[things cut]

|> e. No short cut operators (+= etc.) -- sorry, we've had this debate
|> already in another thread, I've heard the objections, I still like the
|> operators.

Could someone summarize the objections against short cut operators, because
I think that they are great and I 'm quite surprise that they don't exist in
Ada. No need to start a flamewar, I suppose that as with many construct there
are pros and cons. It's just that I can't see why those operators could be bad.


-- 
Renaud HEBERT		e-mail: Renaud.Hebert@prism.uvsq.fr

Re: An observation of Ada (may offend)

[John Volan]

hebert@prism.uvsq.fr (Renaud HEBERT) writes:

>In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes:
>|> e. No short cut operators (+= etc.) -- sorry, we've had this debate
>|> already in another thread, I've heard the objections, I still like the
>|> operators.

>Could someone summarize the objections against short cut operators, because
>I think that they are great and I 'm quite surprise that they don't exist in
>Ada. No need to start a flamewar, I suppose that as with many construct there
>are pros and cons. It's just that I can't see why those operators could be bad.

There's nothing wrong with the notion of short-cut arithmetic
*procedures*.  It's the idea of short-cut arithmetic *operators* that's
the problem.  

I think it would be quite nice if Ada included some built-in
procedures that provided short-cut arithmetic.  Perhaps these could be
in the form of attributes: For every numeric type T, we'd have
attribute procedures such as:

  procedure T'Increment (What : in out T);            -- analogous to ++ in C
  procedure T'Decrement (What : in out T);            -- analogous to -- in C
  procedure T'Increment (What : in out T; By : in T); -- analogous to += in C
  procedure T'Decrement (What : in out T; By : in T); -- analogous to -= in C
  procedure T'Multiply  (What : in out T; By : in T); -- analogous to *= in C
  procedure T'Divide    (What : in out T; By : in T); -- analogous to /= in C

Barring that, it wouldn't be too hard to "roll your own" solution by
writing reusable generic templates for these subprograms.

But to make these into *operators* would entail some difficulties for Ada:

(1) Operators (at least in Ada terms) are functions; they are
subprograms that return a result.  But the point to these short-cut
arithmetic routines is to cause a side-effect on one of their
parameters.  Having a function that causes a side-effect is somewhat
against Ada's design "philosophy".

(2) IMHO, the whole notion of a return value from this kind of
subprogram is totally extraneous anyway.  The whole point of such a
subprogram is, after all, to cause that side-effect, so the idea of an
incidental return value just adds an unnecessary complication.
Witness the contortions C++ gets into due to the subtle difference
between pre-increment ( ++x ), which returns the value of x *after*
incrementing it, versus post-increment ( x++ ), which returns the value of
x *before* incrementing it.

(In fact, this leads me to pose a question: What is the value of C++?
Does it really provide an *improvement* on C, or does it just yield the
*same* *result*?  Maybe they should have called it ++C instead!!!)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

(3) Operators are special symbols, with special syntax (infix, prefix,
postfix), and special semantics (precedence levels).  The syntax and
semantics of the operators we all learned in grade school ( + - * / )
were hard enough to master.  Why gratuitously invent new ones, when you
can do the same job using ordinary subprogram syntax and semantics?
(See my proposed attribute procedures above.)  The only benefit of
short-hand operator symbols is that they make it more convenient for
someone to *write* code -- at the cost of *readability*.  The
philosophy behind the design of Ada was to optimize for readability,
even at the expense of writability, on the assumption that more time
will be spent trying to read and understand Ada code than to write it.

				-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: An observation of Ada (may offend)

[Robert Dewar]

Regarding +:= operators etc, the best thing is to find an archive of CLA
and read the long thread on this subject from earlier this year.

Re: Is Ada the future? [was: Is C++ the future?]

[Robb Nebbe]

In article <milodCx46t7.FIB@netcom.com>,
   milod@netcom.com (John DiCamillo) writes:

|> Languages are not maintainable.  Rather, programs are main-
|> tainable.  A good language and environment coupled with
|> dedicated engineers and good development practices can pro-
|> mote the generation of maintainable code.  In what specific
|> ways does Ada9x promote program maintainability that are
|> *not* provided by C++ or Eiffel?

In my opinion there are two important factors that make software
maintainable. The ability to define an abstraction and have the
compiler enforce this abstraction and the ability for the person
doing the maintenance to understand the abstraction.

For defining and particularly enforcing an abstraction you could
make a fairly strong case that Ada is better than C++. The case
wouldn't be that you can't define and enforce an abstraction in
C++, which would be a bit naive, but that in some cases the effort
required goes far beyond what is required in Ada.

Understandability is probably more closely related to the quality
of the code than the language used but I know for a fact that the
language has at least some influence. I have yet to see any Ada
code as badly written as some of the C I have seen (not even close
in fact).

- Robb Nebbe

Re: Is Ada the future? [was: Is C++ the future?]

[Val Kartchner]

In article <1994Oct4.090807@di.epfl.ch>,
Robb Nebbe <Robb.Nebbe@di.epfl.ch> wrote:
|In my opinion there are two important factors that make software
|maintainable. The ability to define an abstraction and have the
|compiler enforce this abstraction and the ability for the person
|doing the maintenance to understand the abstraction.
|
|For defining and particularly enforcing an abstraction you could
|make a fairly strong case that Ada is better than C++. The case
|wouldn't be that you can't define and enforce an abstraction in
|C++, which would be a bit naive, but that in some cases the effort
|required goes far beyond what is required in Ada.

Ada 83 is *very* strict about enforcing the abstraction.  (i.e.:
private data types are *only* accesible through the defined interface.)
As a programmer who uses Ada 83 at work daily, this is both a blessing
and a curse.  But since I wrote the package, I can just add a necessary
function to the interface.  ;-)

I have also been reading about Ada 9X.  In the booklet "Introducing Ada
9X", Section 2.7, "Hierarchical Libraries", pp 20-23 and Section 2.8,
"Private Child Units", pp. 24-26 have text and code examples which
demonstrate these secion summaries (in the report's own words):

   The important special visibility rule is that the private part (if any)
   and the body of the child have visibility of the private part of their
   parent.

   The private part and body of any child can access the private part of
   its parent (and grandparent...).

Unless there is some subtlty that I've missed in the pages of *both* text
and code, all that one has to do to get access to the private datatypes
is to declare a child package.  (Note: this doesn't include renaming of
private interfaces, but does allow the foreign child to call private
interfaces and thereby effectively rename a private interface.)

Would an Ada programmer /ever/ knowingly defeat the intent of the package
interface and do this?  No, I don't think so.  Do you?  :-S

-- 
|================= #include <stddisclaimer.h> ================/// KB7VBF/P11 =|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State  |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\///   University  |
|=== "I think, therefore I AMiga" -- val@cs.weber.edu ====\///= Ogden UT USA =|

Re: Child packages [nn,pedo,incest,cons]

[Robert I. Eachus]

In article <1994Oct17.091621@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > But you have to want to shoot yourself in the foot. I would think it
 > would be almost impossible to "accidently" declare a child package
 > and muck around with private information.

   Never underestimate stupidity, you can't overestimate it.

   "Against stupidity, the Gods themselves contend in vain." Schiller(sp?)

   You have to know why it is a bad thing. There are no warning signs
posted.  And I don't expect people to spend lots of effort adding
comments to package specifications explaining what catastrophes can be
created by illegitimate children.

   Also, it is possible to write packages so that illegitimate
children are inherently safe.  It takes a little more effort, but
since it is possible many coding practices will favor it.

   But look what happens when someone whose entire experience was in
such an envirionment moves to a company with different practices.

   Maybe what we need are a few "stickers."  One line comments to be
put as the first thing in a private part and explain the relative risk
of illegitimate children:

   "This package is designed to freely allow child units to be added."

   "Any child unit which updates state in this private part must
observe the locking protocol."

   "This subsystem was not designed to allow addition of child units.
User defined child units may be broken by new implementations of the
subsystem."

   "This package will break in the presence of unanticipated child units."

    I guess I'll have to start doing that for Ada 9X code.  They
certainly belong in any published code (including in RM9X) but there
is a lot of Ada 83 code around without the stickers on it.

    (I'll turn this into an "official" 9X comment.  The private parts
of all the language defined packages say:

    private
      ... -- not specified by the language
    end...

    At a minimum, either paragraphs 1.1.3(18-19) should specify that
not specified is the same as unspecified, or all those comments shoul
change.  But I think the best idea would be to also explicitly define
for which language defined packages, if any, user defined children
should not take advantage of visibility into the private part.  (As I
indicated, and I hope as implementors will do it, it should be
possible to allow (implementation dependant) user defined child units
for most language defined packages without risk.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Child packages

[Robb Nebbe]

In article <EACHUS.94Oct17115240@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
|> In article <1994Oct17.091621@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
|> 
|>  > But you have to want to shoot yourself in the foot. I would think it
|>  > would be almost impossible to "accidently" declare a child package
|>  > and muck around with private information.
|> 
|>    Never underestimate stupidity, you can't overestimate it.
|> 
|>    "Against stupidity, the Gods themselves contend in vain." Schiller(sp?)
|> 
|>    You have to know why it is a bad thing. There are no warning signs
|> posted.  And I don't expect people to spend lots of effort adding
|> comments to package specifications explaining what catastrophes can be
|> created by illegitimate children.
|> 

It is sort of like a rail at the edge of a cliff to keep people
from falling off. Something simple is sufficient but if you want
to worry about all the really stupid people then maybe you should
put up a 12 foot high barier in plexiglass or something. I think
that would really enhance places like the Grand Canyon. :-)

I find that child packages make my code safer. They frequently 
replace things like unchecked conversion where I know that it
will always work but I couldn't get Ada83 to check it without
giving up information hiding. I feel a little safer knowing that
the compiler can check everything and that some accidental error
didn't slip in when I had to use unchecked conversion.

As far as illegitemate child packages I find that there are plenty
of warning signs along the way. To write a child package you have to
preference the package name with the name of the parent(s). When
you with the package you have to give the full name including the
parent(s).

I don't buy the arguement that a stupid programmer might declare a
child package by accident. That a programmer might do something
wrong on purpose seems more like paranoia than anything worth
getting concerned about.

A version control system seems like a much better place to worry
about who can do what to which packages.

- Robb Nebbe

Re: Child packages

[Robert I. Eachus]

In article <1994Oct18.103131@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > It is sort of like a rail at the edge of a cliff to keep people
 > from falling off. Something simple is sufficient but if you want
 > to worry about all the really stupid people then maybe you should
 > put up a 12 foot high barier in plexiglass or something. I think
 > that would really enhance places like the Grand Canyon. :-)

   I don't think we disagree.  I think a simple railing is sufficient,
although a low stone wall may be more aesthetically pleasing.  As I
said, originally I was opposed to illegitimate children, but in the
current design, they are a net win.

   But I do think that the packages that are like scenic lookouts on
cliff edges do need the railings.  For example, if a creation function
does more than just create objects, then a note in the private part to
that effect may avoid a few missteps.  A horrible but perfectly
natural example would be a package with a private type which is a
pointer to a record type declared in the private part.  In the
implementation the create operation would do the needed locking, and
the initial value operations on the hidden type count on the locking
having been done.  A one line comment in the hidden object type can
save a lot of grief.  (The alternative is to put the hidden type in
the pacakge body.  That is why such a package is the programming
equivalent of an attractive nuisance.)




--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Child packages

[Robert Dewar]

One thing that should be emphasized about child packages (since some of
the posts of this thread have not been clear on this point) is that
child packages in no way change their parents. If you have a parent A,
and a child A.B, then if A.B does horrible things to the abstractions
in A, it still does not affect anyone who with's only package A. It is
only if package A.B is with'ed that the effects of the child are
noticable.

Re: Child packages

[Robert I. Eachus]

In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

 > One thing that should be emphasized about child packages (since some of
 > the posts of this thread have not been clear on this point) is that
 > child packages in no way change their parents. If you have a parent A,
 > and a child A.B, then if A.B does horrible things to the abstractions
 > in A, it still does not affect anyone who with's only package A. It is
 > only if package A.B is with'ed that the effects of the child are
 > noticable.

     Very misleading.  If a PROGRAM doesn't include any withs of a
child, the child is not part of that program and can't harm it.  But a
child unit can--even during elaboration--change hidden state in the
parent's private part.  So a child added by one portion of a large
project can harm other users of the parent package and it can be very
hard to track down.  This risk on large projects should not be
understated.  (And, yes, project management tools can control or
eliminate the problem, but these tools do not yet exist for Ada 9X.
At least tools which address this particular issue.)

     Note that on many projects the interfaces between subsystems are
specified as packages with only type and subprogram declarations in
the public part.  If 9X were only used for new projects, the simple
solution would be to outlaw state in the private part as well.  As it
is, the solution is to strongly restrict children of such packages.

     As I said, child units like fire are a net win.  But we still
need to learn how to handle them safely.  They can easily be abused.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Child packages

[Norman H. Cohen]

In article <EACHUS.94Oct19110308@spectre.mitre.org>, eachus@spectre.mitre.org
(Robert I. Eachus) writes: 

|>                   If 9X were only used for new projects, the simple
|> solution would be to outlaw state in the private part as well.  As it
|> is, the solution is to strongly restrict children of such packages.

No, as the other article I just posted illustrated, a child can be used
to violate the representation variants maintained for ADTs even by
stateless packages.  The only solution is to treat the writing of a child
for a package as tantamount to modifying the text the parent, and to
impose the same access controls.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Child packages

[Robert Dewar]

Norman, there is still a big difference between modifying the text of a 
package and adding a child, much to big for tantamout :-)

The big difference is that if you modify the text of a package you can
blow up existing clients of that package in different programs.

If you write a child, it is completely separate, and affects on programs
that use the child,

so the level of access controls needed is quite different. a given program
may want to lock out any additional child units, and another program may
wish to allow them, but neither could permit the mucking with a shared
package's text.

Re: Child packages

[Norman H. Cohen]

In article <38496c$1l1@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> Norman, there is still a big difference between modifying the text of a
|> package and adding a child, much to big for tantamout :-)
|>
|> The big difference is that if you modify the text of a package you can
|> blow up existing clients of that package in different programs.
|>
|> If you write a child, it is completely separate, and affects on programs
|> that use the child,
|>
|> so the level of access controls needed is quite different. a given program
|> may want to lock out any additional child units, and another program may
|> wish to allow them, but neither could permit the mucking with a shared
|> package's text.

This is true.  I should have said that adding a child is tantamount to
modifying a program's OWN COPY of a package.  (The point is that
encapsulation in a package provides no more protection against breaking
an abstraction by writing a child than it does against breaking an
abstraction by modifying the text of the package.  Access controls CAN
provide such protection, and I agree that child packages facilitate
access controls with a finer granularity.)

Even the comparison of a shared package with a program-specific child to
a program-specific copy of the package is not quite right, of course,
because a change to the shared copy is immediately reflected in each
program-specific copy.

Some changes to a shared parent may invalidate assumptions on which
children depended, thus breaking program-specific virtual copies of the
package.  However, others may not.  For example, if a bug is found in the
body of a subprogram provided by the parent, causing the subprogram to
violate its specifications in obscure cases, a fix to the parent package
immediately fixes the bug in all programs that use the package or its
children.  (If a program exploited the bug as a "feature", the bug fix
will break that program, but given my hypothesis that the bug violated
the subprogram's specifications, the fault in that case lies with the
program.)

The issue of maintaining a parent package shared by multiple programs
brings out a serious drawback of child units.

One of the breakthroughs provided by Ada 83 was the separation of a
module into distinct textual regions defining a module's interface (the
package visible part) and its implementation (the private part and body).
In languages not providing this clear textual distinction, it is common
to speak of "documented features" and "undocumented features" rather than
properties of the interface and properties of the implementation.  In Ada
83, the maintainer of a package always had complete freedom to change the
details of the implementation.  (Caveat unchecked-convertor.)

In Ada 94 there is a third category of features.  Between the interface
that may be exploited by clients and the implementation details that the
parent-package maintainer reserves the right to change, there is a set of
IMPLEMENTATION features that the package maintainer agrees to leave
unchanged, in the expectation that child units may exploit these
features.  (This distinction is analogous to the C++
public/protected/private trichotomy.)  Unfortunately, the distinction
between "private" implementation details (which even children should not
exploit) and "protected" implementation details (hidden from ordinary
clients but part of the interface as far as child units are concerned) is
not reflected in any way in the text of a parent package, except of
course in comments.  Thus we are back to distinguishing between
"documented features" of a package implementation and "undocumented
features".  (We would like to hope that the so-called "undocumented
features" are actually clearly DOCUMENTED, in comments, as not to be
relied on by child units!)

While child packages provide many more advantages than disadvantages, I
feel we have lost something important from Ada 83--a clearly marked,
compiler-recognized distinction between those aspects of a module that do
and do not form a part of its "contract".

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Child packages

[Robert I. Eachus]

In article <385thq$kh6@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > While child packages provide many more advantages than
  > disadvantages, I feel we have lost something important from Ada
  > 83--a clearly marked, compiler-recognized distinction between
  > those aspects of a module that do and do not form a part of its
  > "contract".

   Exactly!  And there may be no better way to "fix" this problem than
the current language specification.  The problem is not that you can't
write Ada 9X code so that the private part is exactly the contract
with the child units, but that there is a lot of Ada 83 code that is
not written this way.  (Note that one method of making it explicit is
to move some declarations from the private part to a private child.)

    With education and tool support, the problem should disappear
relatively quickly as old code is updated to new standards.  I'm sorry
if Robert Dewar doesn't think that comp.lang.ada is the right place to
discuss those issues.  Back to the previous idiom, I am not objecting
to all the new senic lookouts.  I am just trying to make sure that the
fences there look pleasing, don't interfere with the view, and do
provide the needed safety.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Child packages

[Benjamin Ketcham]

In article <EACHUS.94Oct20110915@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
[...]
>    With education and tool support, the problem should disappear
>relatively quickly as old code is updated to new standards.
[...]

Wait, I thought the benefit of Ada (even Ada 83, which is, after
all, still the only validated standard, isn't it?) was that you
didn't *need* to "update old code to new standards" because the
standard was so safe and readable and mission-critical and a
whole bunch of other things that supposedly justify paying ten
times as much up front, because it will last ten times as long
and maintenance costs will be lower and so you'll save money in
the long run and....

So which is it?  Will the "problem" "disappear relatively quickly"
because all that "legacy" Ada code that was supposed to last 1000
years now needs to be changed to the Even Better, Enhanced, Last
Language You'll Ever Need (And This Time, We Mean It) standard?
Or will the "problem" be hanging around for *decades* because all
that yucky Old-Style Ada 83 just keeps going, and going, and....

<picture your favourite emoticon here>

--ben

Re: Child packages

[Robert I. Eachus]

In article <386eru$8m7@nntp1.u.washington.edu> bketcham@u.washington.edu (Benjamin Ketcham) writes:

 > Wait, I thought the benefit of Ada (even Ada 83, which is, after
 > all, still the only validated standard, isn't it?) was that you
 > didn't *need* to "update old code to new standards" because the
 > standard was so safe and readable and mission-critical and a
 > whole bunch of other things that supposedly justify paying ten
 > times as much up front, because it will last ten times as long
 > and maintenance costs will be lower and so you'll save money in
 > the long run and....

 > So which is it?  Will the "problem" "disappear relatively quickly"
 > because all that "legacy" Ada code that was supposed to last 1000
 > years now needs to be changed to the Even Better, Enhanced, Last
 > Language You'll Ever Need (And This Time, We Mean It) standard?
 > Or will the "problem" be hanging around for *decades* because all
 > that yucky Old-Style Ada 83 just keeps going, and going, and....

   The particular situation I was discussing involved legacy code,
which didn't need to be changed to compile to meet the new standards.
The code was then extended using Ada 9X features.  The "problem" I was
addressing was not the in the old code, or the new code, but educating
programmers about the new features.  If someone wants to use Ada 83
techniques forever, God Bless.  But if a program or a programmer wants
to start using the new features, it is up to us to let them know where
the potential pitfalls are so they never have to fall in.

 > <picture your favourite emoticon here>

   Okay ;-)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Child packages

[Bob Duff]

In article <385thq$kh6@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>While child packages provide many more advantages than disadvantages, I
>feel we have lost something important from Ada 83--a clearly marked,
>compiler-recognized distinction between those aspects of a module that do
>and do not form a part of its "contract".

This is an interesting point.  Note, however, that the contents of a
package body, and the contents of a *private* child package, are hidden
from clients and from new (public) children.

By the way, this whole discussion has been about what happens when
somebody extends an existing system by adding children.  Don't forget
that a hierarchy of children is a good way to organize a subsystem being
written by one person or team -- we don't need to imagine a separate
organization extending the subsystem in order to find a use for child
units.  A lot of cases that in Ada 83 would be done as a single package
will tend to be split into a hierarchy in Ada 9X.

Note also that the distinction between public and private has never been
perfect in Ada.  If you see (in the visible part of a package):

    Message: constant String := "File not found.";

You can't be sure exactly what information is being exported.  
Is the package promising that this string will always be 15 characters
long, and/or contain exactly those characters?  Or is it merely
promising that the thing is called Message, and it's of type String.
If somebody wants to change the message to be more informative, will
that break existing clients?  We don't know for sure.

Now, you may say that one ought to have made it a function, so changing
the message would only require a change to the body.  Well, perhaps, but
that interface promises less to the client in one respect -- the client
can be sure that a reference to Message above will not have side
effects, and will always produce the same value.  Using a function
doesn't make any such promise.  Furthermore, it's more verbose (by a
factor of 5, if you're counting lines of code), so a lot of people will
choose the constant-declaration way.

-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Child packages

[Bob Duff]

In article <CxzCu0.D8I@inmet.camb.inmet.com>,
I wrote:
>This is an interesting point.  Note, however, that the contents of a
>package body, and the contents of a *private* child package, are hidden
>from clients and from new (public) children.

That's not quite right, of course.  Private children are not hidden from
the *bodies* of their public siblings.
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Child packages

[Mark Biggar, 5172]

In article D8I@inmet.camb.inmet.com, bobduff@dsd.camb.inmet.com (Bob Duff) writes:
> Note also that the distinction between public and private has never been
> perfect in Ada.  If you see (in the visible part of a package):
> 
>     Message: constant String := "File not found.";
> 
> You can't be sure exactly what information is being exported.  
> Is the package promising that this string will always be 15 characters
> long, and/or contain exactly those characters?  Or is it merely
> promising that the thing is called Message, and it's of type String.
> If somebody wants to change the message to be more informative, will
> that break existing clients?  We don't know for sure.
> 
> Now, you may say that one ought to have made it a function, so changing
> the message would only require a change to the body.  Well, perhaps, but
> that interface promises less to the client in one respect -- the client
> can be sure that a reference to Message above will not have side
> effects, and will always produce the same value.  Using a function
> doesn't make any such promise.  Furthermore, it's more verbose (by a
> factor of 5, if you're counting lines of code), so a lot of people will
> choose the constant-declaration way.

I'd say that if you put the above declaration in the visible part of
your package spec then you are pretty well promising that the string
won't change in the future and that users can depend on it always being
15 characters long and containing exactly those characters.

But if you had instead written (in Ada9x, but unfortunataly not in Ada83):

...
	Message: constant String:
    private
        Message: constant String := "File Not Found.";
...

Then all you are promising is that it is a constant string and you
should fell free to change it anytime you want and if a user writes
code that, for example, depends on the string being 15 characters long,
then you can reasonably claim that they are cheating and making use of
a property that you didn't want exported.

Actually, if I was attending a walkthough of a users code and they had
used anything other then Message'Length in either case I would red flag
it.

I know that the above are just personal conventions, but isn't this one
of the major reasons why 9x allows deferred constants of any type not
just private types, and besides users of a package arn't suppose to
peek into private parts anyway, are they?

--
Mark Biggar
mab@wdl.loral.com

Re: Child packages

[Robb Nebbe]

In article <385thq$kh6@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) 
|> 
|> While child packages provide many more advantages than disadvantages, I
|> feel we have lost something important from Ada 83--a clearly marked,
|> compiler-recognized distinction between those aspects of a module that do
|> and do not form a part of its "contract".
|> 
|> --
|> Norman H. Cohen    ncohen@watson.ibm.com

I have found it very helpful to think of child packages as extensions of
the parent package and not as clients of the parent package.

If you have a package that needs access to some "private information" then
you should extend the package with a child package that specifies the
interface to this information. Then make your package a client of the
child package.

- Robb Nebbe

Re: Child packages

[Robert Dewar]

I think it is Robert Eachus who is being misleading and alarmist here. First
of all, it is perfectly possible to write packages now which break the
private type interface, by using unchecked conversion, and do all sorts
of horrible things.

Why is this not a disaster? Because you know from the package (with
unchecked conversion) that is is potentially a problem, and you know
that you DON'T have anything to worry about if the package is not
included in a program.

Exactly the same holds true for child packages. I really think all this
worrying about them is bogus. In fact you are much better off with a
child package than you are if someone simply mucks directly with the
source of a supposedly secure package. OK, you say, we have these wonderful
configuration managers that prevent that sort of thing -- fine have these
wonderful cm's also restrict what people can do with child packages.

The bottom line is that child packages add no fundamental functionality.
There is nothing that you can do with them that you cannot do without them,
including busting abstractions. What they allow is much more convenient
package of a program into components, and indeed some of these components
may be mucking with abstractions, possibly in a naughty way, but you are
still ahead.

Consider the following two possibilities:

   someone has mucked with the source of a critical package and broken the
   abstraction. All programs that with this package are bust.

   someone has added a child package to a critical package, and broken the
   abstraction. Only programs that with the child package are bust.

It seems clear that situation two is a huge improvement over the "ada 83"
way of breaking abstractions represented by situation one. 

Of course you can still illegally muck with packages you shouldn't touch
in Ada 9X, but given the possibility of child packages, it is now practical
to really "lock the door" and forbid any mucking with critical packages and
to forbid the use of unchecked conversions.

This kind of draconian action could be done in Ada 83, but then there is
no way out for an isolated special program to get its hands on the private
data. Ada 9X allows such a method, if you care to permit it.

Re: Child packages

[Matt Kennel]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

:  > One thing that should be emphasized about child packages (since some of
:  > the posts of this thread have not been clear on this point) is that
:  > child packages in no way change their parents. If you have a parent A,
:  > and a child A.B, then if A.B does horrible things to the abstractions
:  > in A, it still does not affect anyone who with's only package A. It is
:  > only if package A.B is with'ed that the effects of the child are
:  > noticable.

:      Very misleading.  If a PROGRAM doesn't include any withs of a
: child, the child is not part of that program and can't harm it.  But a
: child unit can--even during elaboration--change hidden state in the
: parent's private part. 

Question:  do you mean objects declared to be type of the parent
may be harmed due to the fact that there are subclasses of
this parent?  This sounds dumb.  This isn't true, is it?

Of course, if you create a child class which takes some implementation
from a parent sure you might screw up the implementation taken from
the parent, but this should only affect you if you use
objects of the child class, right?

: 					Robert I. Eachus

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: Child packages

[Magnus Kempe]

mbk@inls1.ucsd.edu (Matt Kennel) writes:
:
: : But a child unit can--even during elaboration--change hidden state
: : in the parent's private part.
: 
: Question:  do you mean objects declared to be type of the parent
: may be harmed due to the fact that there are subclasses of
: this parent?

No, that is NOT what was meant.

A child _unit_ is not the same thing as a derived type (a.k.a subclass,
derived class, child class, etc.).

Ada offers hierarchies of types/classes _and_ hierarchies of
packages/modules.  These hierarchies are distinct; they need not
coincide.

Since fans of Eiffel make no distinction between type/class and
package/module, this must be difficult to understand.  Maybe they
should read the Rationale of Ada 9X, available from URL
ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x (v5.0 is the latest).

-- 
Magnus Kempe		"I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry

Re: Child packages

[John Volan]

mbk@inls1.ucsd.edu (Matt Kennel) writes:

>Robert I. Eachus (eachus@spectre.mitre.org) wrote:
>: In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

>:  > One thing that should be emphasized about child packages (since some of
>:  > the posts of this thread have not been clear on this point) is that
>:  > child packages in no way change their parents. If you have a parent A,
>:  > and a child A.B, then if A.B does horrible things to the abstractions
>:  > in A, it still does not affect anyone who with's only package A. It is
>:  > only if package A.B is with'ed that the effects of the child are
>:  > noticable.

>:      Very misleading.  If a PROGRAM doesn't include any withs of a
>: child, the child is not part of that program and can't harm it.  But a
>: child unit can--even during elaboration--change hidden state in the
>: parent's private part. 

>Question:  do you mean objects declared to be type of the parent
>may be harmed due to the fact that there are subclasses of
>this parent?  This sounds dumb.  This isn't true, is it?

>Of course, if you create a child class which takes some implementation
>from a parent sure you might screw up the implementation taken from
>the parent, but this should only affect you if you use
>objects of the child class, right?

Matt, you are confusing child units and package hierarchies with
inheritance and class hierarchies.  They are not the same thing.
Child units and package hierarchies are a pure "modularity" concept,
one that that is new to Ada9X.  The hierarchical library mechanism
deals with issues of scope, visibility, encapsulation, information
hiding, and separate compilation.  On the other hand, class
hierarchies and inheritance, well-known in so many object-oriented
languages, are treated as a "typing" concept in Ada9X, and are
implemented in terms of tagged types, type derivation, and type
extension.

Your background as an Eiffel programmer is showing.  Eiffel is a
language designed to adhere to the principle of 1 MODULE = 1 TYPE.
This principle is the "One and Only True Way" of today's
object-oriented orthodoxy.  But the design of Ada (83 and 9X) makes no
attempt to rigidly follow that orthodoxy.  Mind you, it doesn't
*preclude* the idea of 1 MODULE = 1 TYPE.  Indeed, as I've been trying
to show on another thread, it's possible to adhere to a style of 1
PACKAGE = 1 CLASS even under the most strenuous conditions without
resorting to grotesque workarounds.  However, Ada9X doesn't *require*
you to follow this style as the "One and Only True Way".  In fact,
Ada9X's hierarchical library allows programmers to deal with
modularity issues at levels of granularity *beyond* the class-level
(e.g., "subsystems") -- *without* having to look beyond the
programming language for support. At the same time, it supports
levels of granulatiry *smaller* than the class-level (different
aspects of a class's functionality might be dealt with in different
child units -- well, as long as that functionality doesn't have to
be "primitive").

If you haven't already done so, it might help you to download and read
the Ada 9X Rationale, which is available by anonymous FTP from the
AJPO host, in

	ftp://ajpo.sei.cmu.edu/public/ada9x/rm9x

>--
>-Matt Kennel  		mbk@inls1.ucsd.edu
>-Institute for Nonlinear Science, University of California, San Diego
>-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
>-***     lyapunov.ucsd.edu, username "anonymous".

-- John Volan

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------

Re: Child packages

[Norman H. Cohen]

In article <3816h5$n3g@schonberg.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> One thing that should be emphasized about child packages (since some of
|> the posts of this thread have not been clear on this point) is that
|> child packages in no way change their parents. If you have a parent A,
|> and a child A.B, then if A.B does horrible things to the abstractions
|> in A, it still does not affect anyone who with's only package A. It is
|> only if package A.B is with'ed that the effects of the child are
|> noticable.

On the other hand, a part of a large program that with's A.B can do harm
that will affect parts of the program that with only A.  For example: 

   package Fractions is
      type Fraction_Type is private;
      ...
   private
      type Fraction_Type is
         record
            Numerator   : Integer;
            Denominator : Positive;
         end record;
      -- Representation invariant: 
      --    for X in Fraction_Type, X.Numerator and X.Denominator must
      --    be relatively prime.
      -- All the operations exported by this package that construct
      --    Fraction_Type values preserve this invariant, and the
      --    implementation of "=" depends on it.
   end Fractions;

   function Fractions.Invalid_Fraction
      (Numerator, Denominator: in Integer) return Fraction_Type is
   begin
      return (2*Numerator, 2*Denominator);
   end Fractions.Invalid_Fraction;

A part of the program with'ing Fractions.Invalid_Fraction could place the
value returned by that function in some global data structure.  Another
part of the program that with's only Fractions could fail upon trying to
apply the operations of package Fractions to that value.

(In practice, of course, a "problem child" would be more subtle than this
one, and would presumably do its harm unintentionally.)

--
Norman H. Cohen    ncohen@watson.ibm.com