Re: [Fwd: F22 completes 11% of its Flight tests]

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <388E014A.B8F87F5@ebox.tninet.se>,
	Stefan Skoglund <stetson@ebox.tninet.se> wrote:

>Can we agree on one thing ?
>Every time someone uses a package provided by the vendor
>they do so of their own volution ? ie if i need a LALR parser in
>my program i probably picks up aflex ?

I would agree that _withing_ a vendor supplied package at the
specification level often reflects poor planning.  Ordinarily,
one should define the specification required for the problem
space then _with_ the vendor's package in the package body 
(or even in a separately compiled subpgram) to effect the actual
implementation.  This accomplishes several things: 

     1) The interface is independent of the implementation
     2) A different implementation can be used to effect the
        interface,
     3) Vendor dependencies are hidden from users,
     4) With Ada 95, we can take advantage of private child units,
     5) We are more platform-independent.

These are just a few reasons for hiding vendor supplied packages
when possible.  Granted, it is not always possible or even appropriate.

There is even a valid school-of-thought that suggests no
relying directly on standard Ada library packages at the specification
level.  How often does one need all of the resources of Text_IO, or
Direct_IO. Instead, a package such as Direct_IO can be _withed_ in 
the package body to provide primitives necessary for exporting more
powerful abstractions.  Examples,

         procedure Open_With_Lock ( ... );
         procedure Read_With_Lock ( ... );
         procedure Unlock_File   ( ... );

and other routines, all of which can be implemented through the
services of Direct_IO, for ensuring file security in a task based
product.

So all the fuss about _extensions_ is just that, "fuss."  Experienced
Ada software designers have been avoiding such dependencies for a 
long time. 

Richard Riehle
richard@adaworks.com